Segen oder Sackgasse?

Immer wieder wurde SOAA von den an der Entwicklung beteiligten Unternehmen ins Gespräch gebracht, angekündigt und vielfach sogar beschworen. Auch die Welt der Sicherheitstechnik wird von Standards geprägt, egal ob TCP/IP, OPC, Bacnet, Onvif, H.264 und neuerdings auch SOAA oder RS-485-OSDP.

Proprietäre Lösungen machen aus Sicht vieler Anwender abhängig und werden ungern gesehen. Die Welt der elektromechanischen Zylinder und Beschläge ist ebenfalls von proprietären Lösungen geprägt. Wer elektromechanische Schließsysteme mit übergeordneter Managementsoftware zur Verwaltung der Schließrechte einsetzt, ist auf ein bestimmtes Fabrikat von Zylindern und Beschlägen angewiesen. Wettbewerb durch den Einsatz eines weiteren Fabrikates war nicht möglich. SOAA will das ändern und beschreibt sich als einen „offenen Standard“ mit dessen Hilfe in einem System problemlos elektromechanische Zylinder und Beschläge unterschiedlicher Marken verwendet werden können.

Der Anstoß kam von Seiten der Industrie. Anlässlich der Legic-Partnertage 2011 entstand die Idee, auf Basis von Legic Advant einen Standard zu entwickeln. Ziel war es, ein Transpondersegment mit einer Applikation für elektromechanische Zylinder und Beschläge unterschiedlicher Hersteller zu nutzen und damit die proprietären Lösungen durch einen offenen Standard zu ersetzen, den Anwender unabhängig zu machen und Wettbewerb bei Beschaffung und Unterhalt zu erzeugen.

Von der Idee begeistert und teils von interessierten Industrieunternehmen finanziert, bildete sich eine Entwicklungsgruppe. Dazu gehörten unter anderem EADS, Nedap, Legic, Dorma, Assa Abloy sowie Uhlmann & Zacher. Im Jahr 2012 wurde die Grundlage für eine Spezifikation des Datensatzes erarbeitet; 2013 erfolgte die Fertigstellung der ersten SOAA-Spezifikation auf Basis von Legic Advant. Auf Wunsch von Mifare-Anwendern wurde 2013 eine Spezifikation für Mifare Desfire und 2014 eine Spezifikation für Mifare Classic entwickelt und fertiggestellt.

Mit wenigen Abweichungen zwischen Legic und Mifare ist Struktur, Inhalt und Formatierung des Datensatzes, der zwischen einem Schreib-/Leseterminal, dem Ausweis und den elektromechanischen Schließkomponenten ausgetauscht wird, gleich aufgebaut und gliedert sich zum Beispiel bei Mifare Desfire in vier Files. Das „Info File 0“ begrenzt sich auf eine Größe von 32 Byte und beinhaltet grundsätzliche Informationen zu Version- und Ausweisnummer sowie Angaben zu Einträgen im „Event File 2“ und „Blacklist File 3“. Das „Data File1“ enthält die Zutrittsrechte des Karteninhabers.

Das „SOAA Event File 2“ begrenzt sich auf eine Größe von 192 Byte und beinhaltet Meldungen von den Schließkomponenten wie etwa „Batterie tauschen“, „Zylinder defekt“, „Interner Fehler“, „Freischaltung nicht möglich“, „Gewährte Zutritte“, „Verweigerte Zutritte“, „Blacklist voll“. Die Liste der Meldungen ist umfangreich, erlaubt aber nur maximal 16 Einträge im Segment des Ausweises. Die Einträge werden nach dem Auslesen durch das Schreib-/Leseterminal gelöscht. Die Schließkomponente liest immer den gesamten Eintrag und prüft, ob die eigene Meldung bereits vorhanden ist. Wenn das nicht der Fall ist, wird eine Meldung auf den Ausweis geschrieben beziehungsweise angehängt.

Das „Blacklist File 3“ ist auf die Größe von 64 Byte begrenzt und erlaubt maximal drei Einträge. Jede Schließkomponente soll wiederum 16 Einträge für „blacklisted Cards“ aufnehmen können. Das „Blacklist File“ wird vom Ausweis vollständig eingelesen und von der Schließkomponente geprüft, ob der Eintrag bereits vorhanden ist. Einträge mit abgelaufener Gültigkeitsdauer werden in der Blacklist der Schließkomponente automatisch gelöscht.

Standards vermitteln den Eindruck, bei ihrer Anwendung seien alle Probleme gelöst. Das mag in Einzelfällen auch zutreffen. Bei SOAA ist es allerdings wie bei vielen Standards: auch SOAA ist keine „Plugand-Play-Lösung“, sondern ein „Projekt“ im wahrsten Sinne des Wortes. Für eine SOAA-Implementierung muss die SOAAKompatibilität herstellt beziehungsweise vorhanden sein. Das bezieht sich vornehmlich auf die ZK-Managementplattform, die Ausweise beziehungsweise die Transpondertechnologie und die Infrastruktur der Schreib-/Leseterminals. Eine sorgfältige Konzeption des SOAA-Datensatzes muss erfolgen. Je mehr Daten auf dem SOAASegment des Ausweises gespeichert sind, je größer ist – bei Legic und Advant mit merklichem Unterschied – die Schreib-/ Lesezeit. Entsprechend größer ist auch der Stromverbrauch und desto häufiger müssen die Batterien ausgetauscht werden.

Auf der einen Seite muss also mit den Daten sparsam umgegangen werden, auf der anderen Seite ist zu beachten, dass das SOAA-Segment nicht zu klein angelegt wird und damit mögliche Änderungen beim Detaillierungsgrad des elektronischen Schließsystems (ESS) verbaut werden. Schlussendlich muss auch die ZK-Managementsoftware geeignet sein, einen SOAA-kompatiblen Datensatz zu erzeugen und zu verarbeiten.

Einige Schwachstellen und Engpässe müssen berücksichtigt werden. Die Berücksichtigung unterschiedlicher Servicefunktionen oder die Nutzung von Sonderfunktionen sollte geprüft werden. Die Umsetzung der Aussage „für einzelne Optionen kann SOAA um zusätzliche Dateien erweitert werden“ ist derzeit nicht erkennbar. Fraglich ist auch, ob die Dateigröße des „Event Files“ ausreichend ist. Nach 16 Einträgen „Zugang gewährt“ ist das File voll. Bei häufigen Begehungen während einer Tagesfrequenz kann das sehr schnell passieren. Einige der Schwachstellen und Engpässe sind erkannt worden. SOAA soll daher überarbeitet werden.

Ein SOAA-Projekt sollte auf jeden Fall nach der „Best Practice“ – Methode betrachtet werden. Die Frage, ob SOAA der richtige Ansatz ist, kann nur nach einer ausführlichen und unbelasteten Analyse der Ausgangssituation, der Ziele, der erforderlichen Maßnahmen, der damit verbundenen Kosten, der Eignung der zur Verfügung stehenden SOAA-Lieferanten und des langfristigen Einsparpotenzials entschieden werden. Welches in erster Linie durch die Anzahl der anzuschaffenden Schließkomponenten und dem günstigeren Stückpreis generiert werden kann.

Bisher gibt es nur zwei wirkliche Lieferanten für SOAA-kompatible Schließkomponenten: Assa Abloy und Uhlmann & Zacher. Deister Electonic steht noch am Anfang. Echter Wettbewerb ist das nicht.

Bei der SOAA-kompatiblen ZK-Managementsoftware liegt es auch im Argen. Nedap kann alle drei Transpondertechnologien uneingeschränkt realisieren. ACS kann nur Lösungen für Mifare Desfire liefern, Datasec für Legic Advant und Mifare Desfire. Dorma – obwohl an der Entwicklung aktiv beteiligt – verfügt über keine Lösung und macht auch keine Angaben, wann eine zur Verfügung steht. Kaba hat zumindest etwas geplant.

SOAA ist auf dem richtigen Weg. Von einem Standard kann allerdings noch nicht gesprochen werden. Zu wenige Hersteller machen mit. Der gewünschte Wettbewerb ist noch sehr eingeschränkt und nicht wirklich vorhanden. Wer noch mitmachen wird, ist nicht bekannt. Viele Hersteller scheuen den Aufwand und sind von den Vorteilen nicht überzeugt. Noch gibt es nur wenige realisierte Projekte. Ob SOAA ein Segen oder eine Sackgasse ist, kann nur der Einzelfall zeigen, denn auch bei SOAA steckt der Teufel im Detail.