Erklärung des Konzepts

Die SDDI bietet ein Rahmenwerk als Antwort auf die in den vorherigen Kapiteln beschriebenen allgemeinen Herausforderungen dar. Sie repräsentiert einen Ansatz, wie man die Umsetzung einer Dateninfrastruktur mit offenen und standardisierten Schnittstellen realisiert.

Die folgenden Abschnitte erläutern zunächst mögliche Herangehensweisen und Konzepte für die Datenintegration in Projekten in smarten Städten und Regionen. Anschließend wird die Idee hinter der SDDI sowie deren Aufbau erläutert.

Verteilte Daten und Systeme

Verteiltes System, statt zentrale Datenplattform
Eine empfohlene Herangehensweise zur Datenintegration ist es, ein verteiltes System aufzubauen, anstatt eine einzige zentrale Datenplattform zu nutzen. Dadurch kann jeder Dateneigentümer die volle Kontrolle über seine Informations-Ressourcen behalten, es besteht keine Abhängigkeit zum Betreiber einer zentralen Plattform und der Zugriff auf die originären, verteilten Quellen erlaubt es, immer die aktuellsten Daten zu nutzen. Einigen sich mehrere Dateneigentürmer auf eine gemeinsame Plattform, so kann selbstverständlich auch diese in ein verteiltes System eingebunden werden.
Eine Service-Orientierte Architektur hilft bei der kombinierten Nutzung von Komponenten aus verteilten Systemen

Mithilfe einer Service-orientierten Architektur (SOA), auch dienstorientierte Architektur genannt, können verteilte Systeme strukturiert und Komponenten der Systeme in verschiedenen Kombinationen genutzt werden. Ansatz der SOA ist es, die einzelnen Komponenten eines Systems so zusammenzufassen, dass sie als Ganzes in verschiedenen Kontexten verwendet werden können. Dadurch steigen der Wert und die Nützlichkeit einzelner Ressourcen, und aufgrund von möglicher Mehrfachverwendung ist es möglich Redundanz zu vermeiden, indem nicht für jeden einzelnen Anwendungsfall ein neues System aufgebaut werden muss.

Eine zentrale Katalogisierung ist essentiell um den Überblick in einem Smart-City Projekt zu behalten
An die Stelle einer zentralen Datenplattform rückt in einem verteilten System (in einer SOA) ein zentraler Katalog, der nicht die Daten selbst speichert, sondern darüber Auskunft gibt, wo, von wem und unter welchen Bedingungen welche Informationsressourcen zur Verfügung gestellt werden. Die Katalogplattform hilft dabei, den Überblick über die verteilten Informationsressourcen zu behalten, indem sämtliche Daten, Software, IoT-Geräte, Sensoren, Anwendungen, usw. dort registriert sind. Um eine gute Verwaltung und Nutzbarkeit zu gewährleisten gibt es bestimmte Anforderungen an einen solchen Datenkatalog. Zum einen ist es wichtig den Zugriff auf bestimmte Ressourcen einschränken zu können, wenn diese nichtöffentliche sind. Zum anderen bedarf es guter Such- und Indexfunktionen, um relevante Datensätze schnell und einfach zu finden. Zu jedem Eintrag im Katalog sollte der Dateneigentümer einen Link zur Original-Ressource bereitstellen, da der Katalog lediglich ein Auffinden aller Informationsressourcen, nicht aber deren Speicherung selbst übernehmen soll (Stichwort: verteilte Systeme).
Standardisierte und offene Datenschnittstellen helfen bei der Interoperabilität

Die Herausforderung, eine Infrastruktur für die städtische bzw. regionale Datenintegration aufzubauen, wird nicht über die Frage entschieden, ob Open- Source- oder kommerzielle Software eingesetzt werden soll. Der Kernpunkt ist vielmehr, von allen Arten von Software zu verlangen, dass sie offene Standards und Schnittstellen unterstützen. Dies erleichtert den vollständigen Wettbewerb zwischen Softwareprodukten, unabhängig davon, ob sie von Unternehmen hergestellt und lizenziert oder von Entwicklergemeinschaften als Open Source erstellt werden und frei verfügbar sind.

Open Source Implementationen fördern die Transparenz
Es gibt viele Argumente, die für den Einsatz von Open-Source-Software sprechen: z.B. keine Lizenzgebühren, uneingeschränkter Zugang zum Quellcode und oft große internationale Entwicklergemeinschaften. Open-Source-Implementierungen sind auch hilfreich, um eine niedrige Eintrittsbarriere zu haben und Menschen innerhalb der akademischen Welt sowie einzelne Enthusiasten zu motivieren, Dienstleistungen zu entwickeln und mit Datenressourcen beizutragen. Es gibt jedoch auch gute Gründe, kommerzielle Software einzusetzen. Zum Beispiel sind bestimmte Software-Werkzeuge, wie komplexe Simulationssysteme auf der Grundlage von tiefem Spezialwissen einiger Firmen entstanden. Die zur Verfügung gestellten Funktionalitäten sowie die effiziente Art und Weise, wie diese Funktionalitäten implementiert werden, machen oft den Wettbewerbsvorteil und damit die wirtschaftliche Basis für den Softwarehersteller aus. Bei kommerzieller Software ist der Support - zumindest für einen bestimmten Wartungszeitraum - garantiert. In vielen Fällen werden bei kommerzieller Software eher die Aspekte Benutzerfreundlichkeit und Robustheit (insbesondere hinsichtlich der Benutzerschnittstellen) und Skalierbarkeit berücksichtigt im Vergleich zu Open Source. Ebenfalls gibt es gemischte Modelle, bei denen Unternehmen Benutzerunterstützung, Anpassung, Markenbildung, Rollout-Support und Wartung für Open-Source-Software anbieten. Als Fazit lässt sich festhalten, dass eine Dateninfrastruktur für smarte Städte und Regionen sowohl die Nutzung von kommerzieller als auch von Open-Source-Software ermöglichen sollte. Der Schlüssel beim Aufbau der Dateninfrastruktur ist die Gewährleistung der Interoperabilität und die Vermeidung von Herstellerabhängigkeiten, was durch die Verwendung offener Standards für Datenmodelle und offener Schnittstellen erreicht wird. Dieser Leitfaden soll als Entscheidungshilfe dienen, um die relevanten Software- und Hardwarekomponenten für eine Dateninfrastruktur nach der SDDI-Methode zu finden und zu integrieren.
Offene standardisierte  APIs (eng. application programming interface) sind nicht ausreichend, standardisierte Schnittstellen sind entscheidend für eine offene Dateninfrastruktur

Viele kommerzielle Unternehmen bieten bereits jetzt den Zugang zu den Funktionalitäten ihrer Softwaresysteme über offene Programmier-Schnittstellen (Open standardisierte APIs) an. Durch die Bereitstellung offen dokumentierter APIs ermöglichen die Firmen den Benutzern und Entwicklern, die jeweiligen Softwaresysteme von / innerhalb ihrer eigenen Anwendungen aus zu bedienen, zu steuern, auf sie zuzugreifen und sie zu integrieren. Während die Bereitstellung offener APIs eindeutig einen Mehrwert darstellt, der die Nutzung bestimmter Softwaresysteme attraktiver macht, löst sie das Problem der Datenintegration in smarten Städten und Regionen nicht, solange die API und die verwendeten Datenmodelle und Austauschformate nicht standardisiert sind.

Der Programmcode einer Anwendung, der die Funktionalitäten eines Softwaresystems eines Drittanbieters nutzt oder einbettet, muss sich auf die API verlassen und wird dadurch von ihr und dem Unternehmen, das sie definiert, abhängig, was zu einer Herstellerbindung führen kann. Es ist wichtig, daran zu denken, dass offene standardisierte APIs jederzeit und ohne Rücksprache mit Kunden und Benutzern von der besitzenden Firma geändert, modifiziert und ersetzt werden können. Tatsächlich geschieht dies regelmäßig, zum Beispiel bei den offenen APIs von Softwarelösungen großer Unternehmen wie Google und Microsoft. Wenn man eine Anwendung bauen will, die z.B. sechs verschiedene Plattformen oder Systeme miteinander verbindet, muss der Anwendungsentwickler die Änderungen von sechs APIs überwachen und anpassen, was im Grunde genommen eine sehr häufige Aktualisierung dieser Anwendung allein aufgrund von Änderungen an den Schnittstellen zu Drittsystemen erfordert - möglicherweise einmal pro Woche oder alle paar Wochen. Dieses Wartungsniveau kann normalerweise nur von Anwendungs- oder Lösungsanbietern aufrechterhalten werden, die einen Teil ihres Entwicklungsteams für solche Aufgaben einsetzen können. Für kleinere Unternehmen und IT-Abteilungen öffentlicher Einrichtungen ist dies kaum zu bewältigen.

Manchmal weisen Unternehmen mit offenen, aber proprietären APIs darauf hin, dass sie Standards wie JSON oder XML für die Datenkodierung oder REST-basierte Web-Service-Schnittstellen für die Verbindung zu ihren Plattformen verwenden. Die Aussagekraft dieser Angaben ist jedoch begrenzt. Praktisch alle Software-Plattformen - einschließlich derer, die standardisierte APIs, Datenmodelle und Austauschformate verwenden - verwenden diese grundlegenden technologischen Webstandards. Dennoch sind alle proprietären offenen APIs der verschiedenen Unternehmen aufgrund unterschiedlicher Protokolle, unterschiedlicher Strukturen und Bedeutungen der Datenelemente sowie unterschiedlicher Zugangskontroll- und Nutzer-Verwaltungsmechanismen nicht miteinander kompatibel.

Eine Lösung, proprietäre Systeme, die offene APIs anbieten, anzubinden, besteht darin, Übersetzer oder Fassaden zu bauen, die einerseits standardisierte APIs, Datenmodelle und Austauschformate anbieten und die andererseits an die offene, aber proprietäre API des Systems anschließen. Anwendungen können dann standardisierte APIs verwenden, um mit proprietären Plattformen und Systemen zu arbeiten. Dies gilt allgemein für jegliche Systemkomponente, wird in der Praxis aber speziell für den Bereich Internet der Dinge (IoT) für die Vielzahl offener standardisierte APIs für Sensoren und deren Beobachtungen angewendet.

Ein verteiltes System hilft Akteure mit ins Boot zu bringen

Sollte ein smarte Städte und Regionen Projekt durchgeführt werden, so sind meist viele Akteure betroffen und müssen zusammenarbeiten. Dies erfordert eine Kombination und gegenseitige Nutzung von Informationsressourcen verschiedener Entwicklungspartner. Da an jedem einzelnen smarten Städte oder smarten Regionen Projekt typischerweise verschiedene Interessengruppen beteiligt sind, ist es nicht sinnvoll zu versuchen, alle verfügbaren Datenressourcen von allen Interessengruppen im Voraus in einem zentralen städtischen Datenspeicher zu sammeln. Dies wird auch durch Datenschutzbedenken und durch den Wettbewerb zwischen mehreren Akteuren behindert. Dies bedeutet, dass die ursprünglichen Datenressourcen bei ihren Produzenten/Eigentümern verbleiben. Daten werden nur für bestimmte Anwendungen oder Projekte zusammengeführt und integriert, in denen die beteiligten Akteure dem ausdrücklich zugestimmt haben. Diese Anforderungen implizieren, dass ein technischer Rahmen für die Datenintegration eine Architektur von verteilten Ressourcen und Funktionalitäten berücksichtigen muss, die bei Bedarf abgefragt und miteinander verknüpft werden können. Wenn solche Vereinbarungen getroffen worden sind, kann die technische Integration auf eine schnelle und einfache Weise erfolgen. Dies kann durch die Verwendung internationaler Standards für die Modellierung, Beschreibung und Darstellung der Datenressourcen sowie für die Anbindung der verteilten Komponenten, die den Zugriff auf Daten, Visualisierungen und Analysewerkzeuge ermöglichen, erreicht werden. Wenn Systeme auf der Ebene gemeinsamer Schnittstellen und Datenaustauschformate interagieren können, haben sie das erreicht, was als syntaktische Interoperabilität bezeichnet wird.

Nicht nur offene Standards und syntaktische Interoperabilität sind wichtig, sondern auch semantische Interoperabilität
Bei der Datenintegration geht es aber nicht nur darum, Zugang und Schnittstellen zu verteilten Datenressourcen bereitzustellen. Dies kann nur als die niedrigste technische Hürde angesehen werden, die es zu überwinden gilt. Sobald Datensätze abgerufen wurden (dies kann auch die Beobachtungsdaten von Sensoren einschließen), muss der Empfänger in der Lage sein, die Bedeutung jedes Datenelements vollständig zu verstehen, um die Daten in Berechnungen und Analysen richtig einzusetzen. Dies setzt voraus, dass nicht nur die Datenaustauschformate standardisiert werden, sondern auch die Bedeutung der im Format kodierten Informationen dokumentiert und die Dokumentation den tatsächlichen und möglichen Nutzern zugänglich gemacht wird. Dieser Aspekt wird als semantische Interoperabilität bezeichnet; er stellt sicher, dass verschiedene Benutzer und Systeme Daten auf die gleiche Weise verstehen. Semantische Interoperabilität kann auch durch die Verwendung internationaler Standards für domänenspezifische Datenmodelle erreicht werden.
Verteilte, Rollen-basierte Zugriffskontrolle schafft Datensicherheit
Bei verschiedenen Akteuren in ein und derselben Dateninfrastruktur ist es wichtig die Integrität von Datensätzen zu bewahren. Sensible Daten dürfen nicht in die Hände von falschen Personen gelangen, gleichzeitig sollte das System so offen und transparent wie möglich sein. Eine verteilte rollenbasierte Zugriffskontrolle ermöglicht es jedem Akteur eine bestimmte Rolle zuzuweisen, mit der der Zugriff auf Informations-Ressourcen gesteuert wird. Eine solche Zuweisung der Akteure ist z.B. mit verschiedenen Organisationen möglich. Jede der Organisationen besitzt einen eigenen Bereich mit sensiblen Daten und eigenen Administratoren, über die neue Mitglieder hinzugefügt werden können. Da das System dezentral und verteilt aufgebaut ist, entfällt die Notwendigkeit die gesamte Rollenverteilung über eine einzelne Person zu organisieren.
Digitale Modelle der bebauten Umwelt zur Informationsintegration nutzen
Betrachtet man mehrere Use Cases für Dateninfrastrukturen und die entsprechenden Anwendungen gleichzeitig, so stellt man fest, dass viele Anwendungen Daten über die gleichen Objekte der realen Welt benötigen. Dies eröffnet Möglichkeiten für Synergien, da bestimmte Datenpakete zusammengefasst und auf einheitliche Weise bereitgestellt werden können, wodurch Redundanz und wiederholte Datenerfassung vermieden werden. Untersuchungen im Projekt SSD zeigten, dass sich die überwiegende Mehrheit der benötigten und angebotenen Daten auf Objekte der physischen Umgebung wie Gebäude, Straßen, Wege, Vegetation usw. bezog. In vielen Fällen standen die Daten in direktem Zusammenhang mit einigen Merkmalen dieser Objekte (Lage, Größe, Ausdehnung, Volumen, Grundfläche) oder mit einigen Teilen dieser Objekte (z.B. im Falle eines Gebäudes die Flächen einer Gebäudefassade, eine Dachfläche oder die gesamte Wohnfläche). In anderen Fällen bezogen sich die Daten nur auf Objekte der physischen Umwelt, z.B. den Heizenergiebedarf, den geschätzten Immobilienwert sowie die CO2-Emissionen eines Gebäudes. Wenn es ein virtuelles Modell des Bezirks (oder einer ganzen Stadt oder Region) gibt, das alle relevanten physischen Objekte durch entsprechende Datenobjekte in einem ausreichenden Grad an thematischer und geometrischer Detailliertheit darstellt, können viele (und manchmal alle) erforderlichen Datenelemente für verschiedene Anwendungen direkt aus einem solchen Modell abgeleitet und in Berechnungen verwendet werden (wie z.B. die Ableitung von städtischen Indikatorwerten). Beziehen zudem verschiedene Akteure Datenelemente oder Sensoren auf dasselbe Objekt im Modell der bebauten Umwelt, werden diese Datenelemente direkt vergleichbar - weil sie sich auf denselben Nenner beziehen (z.B. dasselbe Gebäudeobjekt des virtuellen Distrikt Modells) - und können so leicht kombiniert und gemeinsam ausgewertet werden.
CityGML als standardisiertes Datenmodell für virtuelle Stadt- und Landschaftsmodelle

Im Kontext von SDDI werden solche Modelle mit dem Begriff Virtuelles Distrikt Model (VDM) bezeichnet.

Der internationale Standard CityGML definiert eine Datenstruktur für derartige Modelle. In Bayern können alle im Liegenschaftskataster enthaltenen Gebäude nach diesem Standard bezogen werden. Semantische 3D-Modelle spielen auch im Bauwesen und in der Architektur eine zunehmende Rolle. Building Information Modelling (BIM) ist eine Methode, bei der digitale Modelle verwendet werden, um die Planung, den Bau, den Betrieb sowie die Nachrüstung und den Rückbau von Gebäuden und anderer Infrastrukturobjekte zu unterstützen.

IFC als standardisiertes Datenmodell für Gebäudemodelle aus Architektur und Bauwesen

Mit den so genannten Industry Foundation Classes (IFC) hat die Organisation buildingSmart International (bSI) einen internationalen Standard für die Modellierung von BIM-Modellen und deren Datenaustausch herausgegeben. Eine Reihe von Ländern wie die USA, Großbritannien, Deutschland, Norwegen und weitere haben Vorschriften in Kraft gesetzt, die vorschreiben, dass neue Gebäude oder Infrastrukturobjekte in den nächsten Jahren nach der BIM-Methode geplant und gebaut werden müssen. Dies bedeutet, dass in naher Zukunft für alle neu geplanten und errichteten Gebäude sehr detaillierte semantische 3D-Modelle mit standardisierten Informationsinhalten zur Verfügung stehen werden. Alle Arten von Informationen zu diesen Gebäuden können dann mit den BIM-Modellen in Beziehung gesetzt werden, was die Datenintegration auf semantischer Ebene erleichtert.

Virtuelle Distrikt Modelle der physischen Realität spielen auch eine Schlüsselrolle, wenn es um die Einschätzung und Bewertung der Auswirkungen geplanter Umgestaltungen einer Kommune, Stadt oder Region in Bezug auf Lebensqualität, Umwelt- und Energieparameter, aber auch auf die Mobilität geht. Da viele dieser Parameter und Indikatoren, welche vollständig auf angereicherten virtuellen Bezirks- bzw. Stadtmodellen basieren, durch Simulationswerkzeuge ermittelt oder angenähert werden können, können solche Schätzungen auch für 3D-Modelle durchgeführt werden und "Was-wäre-wenn"-Szenarien erstellt werden. Beispielsweise können die Auswirkungen der Nachrüstung von 30% aller Wohngebäude in einem Stadtteil und die Installation von photovoltaischen Solarpaneelen auf 25% aller geeigneten Dächer und Fassaden auf die Energieproduktion, den Energieverbrauch und die potentielle Reduzierung der CO2-Emissionen berechnet und mit den Kosten und den benötigten Materialien in Beziehung gesetzt werden. Auch die Auswirkungen einer Veränderung der Verkehrsströme einiger Straßen auf den Energiebedarf, den Verkehrslärm und die Luftverschmutzung können analysiert und bewertet werden.
Ein Use-Case orientiertes Vorgehen mit einem „Paten“ sorgt dafür, dass es voran geht

Bei der Umsetzung einer Dateninfrastruktur für Smarte Städte und Regionen gibt es zwei gegensätzliche Herangehensweisen: Es kann zum einen von bereits bestehenden Datensätzen ausgehend nach möglichen Use-Cases gesucht werden, welche sich mit Bezug auf die erhobenen Informations-Ressourcen eignen. Dieser Ansatz ist oft nicht ideal, da er zu stark auf die Nutzung vorhandener Daten fokussiert ist, anstatt auf die tatsächlichen Herausforderungen in einer Kommune, Stadt oder Region einzugehen.

Ein anderer Ansatz, dem dieser Leitfaden zugrunde liegt und der empfohlen wird, ist ausgehend von einer bestehenden Herausforderung die benötigten Informations-Ressourcen zusammenzustellen. Hierbei steht der Aufbau einer Dateninfrastruktur zur Lösung des Problems im Mittelpunkt. Dieser Ansatz wird auch Use Case orientiertes Vorgehen genannt. Er sorgt dafür, dass aus einem Projekt auch tatsächlich ein Nutzen gezogen werden kann. Für die Umsetzung selbst empfiehlt es sich einen sogenannten „Paten“ einzusetzen, also eine Person, die den gesamten Projektverlauf überwacht und lenkt. Ohne einen solchen Paten kommt es oft vor, dass aufgrund von Uneinigkeiten zwischen verschiedenen Projektteilnehmern und einem generellen Unwissen über die genaue Aufgabenverteilung der Fortschritt im Projekt gefährdet ist.

Kriterien für die Wahl eines „Paten“
Um eine geeignete Person für diese Aufgabe zu finden, empfiehlt es sich einige Kriterien zu befolgen. Als geeignete Paten kommen Personen in Frage, die ein gutes Allgemeinwissen innerhalb des gesamten Projekts besitzen. Es nicht zwingend erforderlich einen Experten in sämtlichen Teilbereichen zu finden, wohl aber eine Person zu haben die jeden Teilbereich grundlegend versteht und somit in der Lage ist die richtigen Verknüpfungen zwischen den Bereichen herzustellen. Hierfür empfiehlt es sich auch, eine Person mit guten Verbindungen zu sämtlichen involvierten Partnern einzusetzen, um die Kommunikation innerhalb des Projektes zu erleichtern. Somit kann auf die individuellen Anforderungen und Anliegen der beteiligten Akteure besser eingegangen werden. Gute soziale Fähigkeiten im Umgang mit Menschen und verschiedenen Interessensgruppen erleichtern diesen Schritt ebenfalls. Einer der wichtigsten Aspekte ist es eine Person einzusetzen, die allgemein als vertrauenswürdig gilt, sodass eine Offenheit innerhalb des Projekts und bei jeder beteiligten Partei gefördert wird. Die somit geschaffene Vertrauensbasis ist der Grundstein für eine gute Zusammenarbeit und das Einbringen von individuellem Wissen. Zu guter Letzt empfiehlt es sich eine Person aus dem direkten Umfeld des Use Cases zu berufen, da hierdurch von Haus aus ein guter Bezug zu den beteiligten Akteuren besteht. Wichtig ist dabei, dass es sich um eine neutrale Person handelt, die keinen persönlichen Nutzen aus dem Projekt ziehen kann. Wird eine einzelne Person den Anforderungen des Use Cases aufgrund seiner Komplexität nicht mehr gerecht, kann auch ein Team an Paten eingesetzt werden, solange es eine einzelne Person gibt, die als oberster Ansprechpartner für die Umsetzung zuständig ist.
Ein Digitaler Zwilling wächst mit den Anforderungen unterschiedlicher Use Cases

Der Aufbau eines derartigen, mit Informationen aus verschiedensten Quellen angereicherten virtuellen Modells (= Geobasierter/Urbaner Digitaler Zwilling) einer Kommune, Stadt oder Region ist mit Aufwand verbunden, den eine einzelne Anwendung nicht unbedingt rechtfertigt. Wird nach der SDDI-Methode vorgegangen, so kann ein derartiger geobasierter Digitaler Zwilling schrittweise entstehen und mit jedem neuen Use-Case weiter angereichert werden.

Abb. 2 zeigt stilisiert das Problem von verteilten Ressourcen, welche untereinander in Verbindung stehen, jedoch nicht immer untereinander kompatibel sind. SDDI hilft dabei ein standardisiertes Verwaltungssystem aufzubauen.

Das SDDI-Framework

SDDI als Konzept zum Datenmanagement und zur Datenintegration

Abb. 3 zeigt das Konzept, welches hinter dem Namen SDDI steckt. Diese Grafik ist das Ergebnis von weitreichenden und intensiven Überlegungen, und wurde im Rahmen des SSD-Projekts durch Rückkopplungen aus dem Einsatz der SDDI für Problemstellungen aus der Praxis weiterentwickelt. Insgesamt gibt es sechs Komponenten, welche im Austausch miteinander stehen.

  1. Akteure: Als Akteure werden sämtliche Personen, Behörden, Gesellschaften, Firmen und Verbände bezeichnet, die in irgendeiner Form etwas mit den gesammelten Daten und deren Anwendung und Bereitstellung zu tun haben. Sie können auch als Stakeholder bezeichnet werden. Akteure können verschiedene Rollen in Bezug auf die SDDI einnehmen (siehe Kapitel „Akteure und ihre Rollen“), von der Bereitstellung einzelner Komponenten bis zur Nutzung von Anwendungen für die Entscheidungsunterstützung.
  2. Anwendungen/Apps: Mit Hilfe von Anwendungen/Apps haben die Akteure Zugriff auf die zur Verfügung stehenden Informations-Ressourcen. Die SDDI umfasst dabei ein breites Spektrum an möglichen Anwendungen, die in Abbildung 3 aufgeführten, sind lediglich Beispiele. Eine Anwendung/App besteht dabei immer aus einem User-Interface und, je nach Anwendungsfall, auf der Nutzung einer bestimmten Kombination aus IoT-Sensoren, virtuellem Distriktmodell und urbanen Analysewerkzeugen.
  3. IoT und Sensordaten: Zusammengefasst in einer Kategorie sind Internet of Things (IoT) und Sensordaten sowie das Virtuelle Distriktmodell. Erstere sind Quelle neuer Daten wie beispielsweise Temperatur, Luftdruck, Stromverbrauch oder Parkplatzbelegung, und letztere ein virtuelles Modell einer Stadt oder Region mitsamt semantischen Informationen und Möglichkeiten zur Interoperabilität.
  4. Das Virtuelle Distriktmodell (VDM): enthält für jedes wesentliche Objekt des realen Distrikts / der Kommune / Region (d.h. Gebäude und weitere Bauwerke, Straßen, Gewässer, Leitungsnetze, ggf. Vegetationsobjekte etc.) ein korrespondierendes digitales Objekt. Die digitalen Objekte des VDM beschreiben die Objekte der realen Welt hinsichtlich ihrer Thematik, räumlichen Lage, Ausdehnung und Form. Das VDM wird mittels definierter Prozesse laufend aktualisiert, um möglichst immer dem Zustand der realen Welt zu entsprechen. Das VDM ist neben dem SDDI-Katalog eine der beiden SDDI-Kernkomponenten, und dient der Informationsintegration und der räumlichen Visualisierung. So lassen sich über die Objekte des VDM Informationen aus den unterschiedlichsten Quellen miteinander verknüpfen und Informationen räumlich verorten (z.B. IoT-Daten und Ergebnisse von Urbanen Analysewerkzeugen). Wichtiges Merkmal der digitalen Objekte ist, dass sie stabile Identifikatoren besitzen, die als Ankerpunkte zur Informationsintegration genutzt werden können. Das VDM kann in Form eines 2D-Geoinformationssystems oder eines semantischen 3D-Stadtmodells realisiert werden, auf das über offene, standardisierte Schnittstellen, wie OGC Web Feature Service oder OGC API - Features zugegriffen werden kann. Möglich ist auch eine Realisierung in Form eines BIM-Modells. Sind Objekte des VDM besonders wichtig für einen bestimmten Use Case, so können sie im SDDI-Katalog als Einzelobjekte registriert werden. Es bietet sich an, für möglichst viele Objektarten des VDM Daten aus bestehenden Katastern, insbesondere amtliche Geobasisdaten als Grundlage zu verwenden, da für diese bereits Fortführungsprozesse und weitere Daten-Governanceprozesse definiert sind und die Objekte stabile Indentifikatoren besitzen. Das VDM umfasst auch die Funktionalität zur räumlichen Visualisierung. Im Kontext von TwinBy soll das VDM auf der Grundlage der LOD2-Gebäudemodelle der Bayerischen Vermessungsverwaltung realisiert werden, ggf. ergänzt durch weitere Geodaten zu Verkehrs- und Gewässernetzen sowie bereits von den Kommunen oder deren Dienstleistern gepflegten 2D- oder 3D-Geodaten.
  5. Urbane Analysewerkzeuge: Als Urbane Analysewerkzeuge werden verschiedenste Dienste, welche Datenanalysen im städtischen Raum ermöglichen, bezeichnet. Hierfür gibt es eine Vielzahl an Möglichkeiten, die in 3 aufgeführten, sind lediglich Beispiele. Urbane Analyse-Werkzeuge können von Anwendungen entweder direkt aufgerufen werden und die Ergebnisse online produzieren oder die Ergebnisse werden im Voraus berechnet und stehen dann als Datenquelle in der SDDI zur Verfügung.
  6. Katalogplattform: Die Katalogplattform steht im Zentrum der SDDI und verbindet die übrigen Themenfelder miteinander. Sie dient als zentrale Sammelstelle für sämtliche vorhandenen Daten, Dienste und Anwendungen und liefert so eine Gesamtübersicht. Sie stellt eine Kernkomponente dar, die Use-Case-übergreifend und auch bereits im Prozess der SDDI-Implementierung genutzt wird. Im Katalog selbst werden keine Daten und Anwendungen gespeichert, sondern lediglich der Verweis darauf wo die Daten zu finden sind, und wie sie verwendet werden können.

Um Verknüpfungen zwischen den einzelnen Komponenten der SDDI herstellen zu können bedarf es Datenschnittstellen, über die Dienste und Anwendungen kommunizieren können. Die SDDI setzt auf offene und standardisierte Schnittstellen, welche einen einfachen Datenaustausch ermöglichen. Die Datenquellen, Anwendungen und Dienste selbst können dabei proprietär und in vollem Besitz der jeweiligen Eigentümer bleiben, wichtig ist, dass der Datenaustausch funktioniert. SDDI setzt des Weiteren auf einige Prinzipien, welche im Folgenden beschrieben werden.

Die Prinzipien hinter SDDI

Vermeidung von Redundanz in Datensätzen senkt den Arbeitsaufwand und eliminiert Widersprüche
Vermeidung von Redundanz: In vielen Fällen gibt es Datensätze, die ein bestimmtes Objekt der realen Welt beschreiben oder mit ihm in Beziehung stehen. Dieses Objekt ist oft in verschiedenen Quellen oder von verschiedenen Anbietern unterschiedlich definiert. Dies führt zu Mehrdeutigkeit und Redundanz in den Daten. Beispielsweise erfordern Anwendungen wie Energiesimulation, Fußgänger-flusssimulation oder Anwendungen mit Echtzeit-Sensorbeobachtungen in Gebäuden alle die Arbeit mit Informationen über Gebäude, die in jeder der Anwendungen auf eine eigene Art und Weise abgebildet werden. Es ist jedoch weitaus sinnvoller, ein und denselben Datensatz in jeder Anwendung zu verwenden, sodass die Daten zum einen nur einmal erhoben werden müssen, und zum anderen jede Anwendung mit der gleichen Version der Daten arbeitet. Um Datenredundanz zu vermeiden, spielen Standards eine entscheidende Rolle. SDDI ist auf der Grundlage von Standards von Open Geospatial Consortium (OGC) und ISO konzipiert. Hierfür eignet sich beispielsweise die Modellierungssprache CityGML, um Gebäude für alle oben genannten Anwendungen abzubilden, sodass ein einziger Datensatz ausreicht.
Fehlinterpretationen und falsche Verwendung kann durch Datenstandards vermieden werden
Gut spezifizierte Datensemantik: Eine der Herausforderungen besteht darin, dass Daten oft unterschiedlich interpretiert werden. Dies führt im Laufe der Zeit zu einer fehlerhaften Verwendung der Daten durch verschiedene Benutzer. Es ist daher entscheidend, Datenmodelle zu verwenden, welche aussagekräftige Informationen für jeden Benutzer verständlich darstellen. Dies erfordert eine gut spezifizierte Datensemantik. Standards von ISO oder OGC sind gute Beispiele für die Umsetzung einer solchen standardisierten Datensemantik und werden in der SDDI berücksichtigt.
Das Virtuelle Distrikt-modell als Beispiel für einen Baustein in der SDDI
Die beiden Aspekte "Redundanzvermeidung" und "gut spezifizierte Datensemantik" werden beispielsweise durch die Einführung eines virtuellen Distriktmodells (VDM) angesprochen. Das VDM enthält neben Netzen für die Wasserversorgungs-, Smart Grids- oder Verkehr auch Objekte wie Gebäude, Straßen, Stadtmobiliar, Gewässer etc. (Percivall et al. 2015[1]) argumentieren, dass der Raum (Koordinaten, Geometrie) an sich eine grundlegende Methode zur Organisation der Smart City ist. Aus Sicht dieses Leitfadens ist der Raum nicht die einzige Methode, aber semantische Objekte (mit räumlichen Eigenschaften) - wie sie vom VDM bereitgestellt werden - sollten als gemeinsamer Nenner für die Darstellung und Organisation der Informations-Ressourcen aus den verschiedenen Anwendungsbereichen in smarten Distrikten verwendet werden. Unsere detaillierten Analysen der SSD-Deep-Dive-Distrikte (Distrikte mit besonderem Fokus) zeigen deutlich, dass fast alle thematischen und sensorischen Informationen in direktem Zusammenhang mit den Objekten des VDM stehen. Die eingesetzten Sensoren messen Eigenschaften der Objekte der realen Welt (z.B. messen Smart Meter den Stromverbrauch von Gebäuden). Die Verknüpfung der Sensoren mit den jeweiligen Gebäudeobjekten und Gebäudeeigenschaften spezifiziert daher implizit die Semantik der Sensorbeobachtungen. Das VDM ist eine Antwort auf das, was im Datenmanagement der heutigen anderen Smart City-Initiativen weitgehend fehlt. Dabei handelt es sich um die Verwaltung der Daten durch ein gemeinsames digitales Modell der physischen städtischen Umgebung als Informationsdrehscheibe. Dies zeigt sich zum Beispiel in den auf IoT und Big Data-Analyse konzentrierten Smart City-Konzepten, wo offensichtlich das Konzept der Verknüpfung der Geräte mit einem gemeinsamen Datenknoten fehlt. Auf der Grundlage der im SSD-Projekt und durch die Arbeit mit verschiedenen Bezirken gewonnenen Erfahrungen können wir feststellen, dass die Bezirke in fast allen Fällen auf die eine oder andere Weise mit spezifischen Objekten arbeiten oder sich auf diese beziehen müssen. Diese Objekte werden hinsichtlich ihrer Standorte und ihrer physischen Eigenschaften in der realen Welt definiert. Daher ist es notwendig, ein virtuelles Modell dieser physischen Elemente des Gebiets zu haben - sei es nur für einen Bezirk oder für die gesamte Stadt. Das VDM ist auch der Schlüssel für verschiedene Arten von Simulationen (z.B. Energie-, Verkehrs- und Umweltsimulationen) und für die Abschätzung der Auswirkungen geplanter Veränderungen im Bezirk.


[1] PERCIVALL, G., RÖNSDORF, C., LIANG, S., MCKENZIE, D. & MCKEE, L. (2015), OGC Smart Cities Spatial Information Framework, Open Geospatial Consortium, OGC Doc. No. 14-115

Interoperabilität als Basiskonzept der SDDI
Interoperabilität: Nach ISO 2382-1 (vgl. ISO/IEC 10746-2:2009) wird der Begriff der Interoperabilität definiert als "die Fähigkeit, zwischen verschiedenen Funktionseinheiten auf eine Weise zu kommunizieren, Programme auszuführen oder Daten zu übertragen, die vom Benutzer wenig oder keine Kenntnisse über die einzigartigen Eigenschaften dieser Einheiten erfordert". Semantische und Syntaktische Interoperabilität ist eines der wichtigsten Merkmale und eine Schlüsselrolle in der SDDI. Hierdurch werden Hindernisse wie z.B. institutionelle Barrieren überwunden und die Herstellerbindung vermieden, wodurch Offenheit für Erweiterungen geschaffen und der Informationsaustausch ermöglicht wird.
SDDI ist modular und einfach zu erweitern
Erweiterbarkeit: Die Realisierung der SDDI als modularer, offener und interoperabler Zusammenschluss von verteilten funktionalen Komponenten gewährleistet die einfache Erweiterbarkeit um neue Akteure, Benutzer, Sensoren, thematische Informationen und Analysewerkzeuge. Darüber hinaus sollte das Modell nicht nur für den aktuellen Entwicklungsstand konzipiert werden, da sich die verschiedenen Technologien schnell weiterentwickeln. Die Struktur von SDDI selbst ist so konzipiert, dass sie erweiterbar ist, um den zukünftigen Bedürfnissen und Fällen gerecht zu werden.
SDDI ist vielseitig anwendbar
Funktionalität: Eine standardisierte Lösung stellt die Funktionalität des SDDI-Konzeptes sicher. Das bedeutet, dass das SDDI-Modell so gestaltet ist, dass es für verschiedene Anwendungsfälle verwendet werden kann, ohne dass jedes Mal aufwändige Neuimplementierungen vorgenommen werden müssen.
Eine Übertragung des Konzepts von einem Fall auf einen anderen ist leicht möglich
Übertragbarkeit: Das SDDI Konzept wurde nicht für einen einzelnen Anwendungsfall oder einen Bezirk entwickelt, sondern wurde bereits an verschiedenen Orten auf ähnliche Weise implementiert. Diese Eigenschaft von SDDI ist wiederum auf die umfassende Verwendung von Standards in der Infrastruktur zurückzuführen. So gibt es beispielsweise viele Städte auf der Welt, die das 3D-Modell ihrer Städte bereits nach dem OGC CityGML-Standard aufgebaut haben.

Der Katalogdienst - Die zentrale Plattform für alle Informations-Ressourcen

Über die Katalogplattform werden sämtliche Datensätze und Anwendungen referenziert

Die Katalogplattform spielt eine zentrale Rolle in der SDDI. Sie dient als Informationsdrehscheibe und Wissensspeicher, speichert jedoch selbst keine Daten, sondern nur die Verweise darauf wo die Daten zu finden sind und in welcher Form sie vorliegen (=Metadaten). Eine geordnete Struktur und einfache Bedienung erleichtern die Arbeit mit dem Katalog und schaffen einen Überblick über den Gesamtbestand. Im Zuge des Projekts „Geobasierter Digitaler Zwilling“ ist eine Katalogplattform entstanden, welche bayernweit Anwendung findet. Es ist möglich Instanzen dieses Katalogs in einzelnen Regionen aufzusetzen, sofern eine Kommune über die benötigte Infrastruktur verfügt oder einen Dienstleister beauftragt. Der bayernweite Hauptkatalog ist im Stande Einträge aus den regionalen Katalogen automatisch zu beziehen und so einen Gesamtüberblick zu verschaffen. Die Struktur der Katalogplattform wurde nach den Anforderungen und aus den Erfahrungen mehrerer Smart-Städte-Projekte (SSD, SDDI London, Digitaler Zwilling München, Connected Urban Twins)sowie einem Projekt zum Aufbau einer Dateninfrastruktur für die Agrarwissenschaften der TUM (SRADI) entwickelt. Wesentliche Merkmale sind eine übergeordnete Kategorisierung der Katalogeinträge in Hauptkategorien und Themen sowie die Möglichkeit, einzelne Katalogeinträge miteinander zu verlinken.

Jeder Katalogeintrag ist einer Hauptkategorie und beliebig vielen Themen zugeordnet

Um einen besseren Überblick über die Katalogeinträge zu erhalten und die Suche zu erleichtern, ist jeder Katalogeintrag genau einer von acht Kategorien zugeordnet. Diese Kategorien setzten sich zusammen aus: „Datensatz und Dokumente“, „Online-Dienst“, „Online, Anwendung“, „Projekt“, „Software“, „Methode“, „Gerät / Ding“, „Geoobjekt“ und „Digitaller Zwilling". Über eine Auswahl einer dieser Kategorien ist es möglich sämtliche zugehörigen Katalogeinträge anzuzeigen. Abb. 4 zeigt die Hauptkategorien in der Katalogplattform.

Neben den acht Hauptkategorien gibt es noch 16 weitere Themenfelder, die sogenannten Themen. Bei den Themen handelt es sich um Überbegriffe für relevante Handlungsfelder im Bereich von Smarten Städten und Regionen. Die verfügbaren Themen decken daher nicht zwangsläufig sämtliche möglichen Gebiete ab wie es bei den Hauptkategorien der Fall ist. Ein jeder Katalogeintrag kann beliebig vielen Themen zugeordnet werden, es kann dabei auch kein einziges Thema ausgewählt werden. Abb. 5 zeigt die Themenfelder in der Katalogplattform. Die 16 Themenfelder sind identisch mit den 16 Handlunsgfeldern im Smart Cities & Regions Atlas Bayern (https://smart-regions.bayern/). Über eine Auswahl kann auch hier sehr schnell nach Katalogeinträgen, welche ein bestimmtes Thema umfassen, gesucht werden.

Zusätzlich zu den Themen ist es möglich einen Katalogeintrag einer oder mehrerer der Modellregionen zuzuweisen. Dies ist nur im Masterkatalog möglich, in regionalen Instanzen, welche in den Modellregionen selbst betrieben werden, entfällt diese Möglichkeit. Bei einem Harvesting, also einem maschinellen Auslesen der Katalogeinträge des regionalen Katalogs können die entsprechenden Modellregionen auch automatisiert im Masterkatalog der ZD.B-Themenplattform dargestellt werden. Abb. 6 zeigt die aktuellen Modellregionen in der Katalogplattform.

Eine Suche nach Katalogeinträgen ist auch zeitlich und räumlich möglich

Um die Suche nach Einträgen zu erleichtern, setzt der Katalog auf verschiedene Methoden zur Indexierung von Katalogeinträgen. In einem Katalogeintrag ist es neben einem aussagekräftigen Titel und Stichwörtern möglich einen zeitlichen Rahmen zu definieren, in dem der Katalogeintrag seine Gültigkeit besitzt. Anhand dieses Gültigkeitszeitraumes können die Katalogeinträge anschließend gefiltert werden, wobei auch ein einseitig offener Zeitraum, wie beispielsweise ein Projekt, welches noch immer läuft, möglich ist. Die Suche findet dabei Katalogeinträge, sofern sich mindestens ein Tag des Gültigkeitszeitraums im Suchzeitraum befindet.

Jeder Katalogeintrag kann außerdem mit einer geographischen Ausdehnung versehen werden, welche entweder aus einem einzelnen Punkt oder einem Polygon besteht. Beides kann über eine interaktive Karte gezeichnet werden. Die Umrisse von Bayern sowie der sieben Regierungsbezirke sind als vordefinierte Auswahl integriert. Über ein Eingabefeld kann ein beliebiges Polygon als GeoJSON Objekt eingefügt werden, so ist es zum Beispiel möglich die Grenzen einer Kommune als räumliche Ausdehnung des Katalogeintrags ohne viel Aufwand einzutragen. Auch der Katalogeintrag eines einzelnen physischen Objekts, z.B. eines Luftqualitätssensors, kann auf diesem Weg mit einer Geometrie versehen werden, um eine ortsbezogene Suche nach Objekten zu ermöglichen.
Ein Katalogeintrag kann beliebig viele Ressourcen enthalten
Ein Eintrag im Katalog an sich enthält noch keine Daten, sondern lediglich Metadaten, also eine Beschreibung, die auch die oben genannten Attribute enthält. Für die Verlinkung externer Quellen, wie z.B. Webseiten, Webclients, Datenblätter oder Bilder werden im Katalog sogenannte Ressourcen angelegt. Dabei ist sowohl die Eingabe eines URL-Links, als auch ein direkter Dateiupload möglich. Da der Datenkatalog lediglich zum Finden der verfügbaren Informations-Ressourcen, und nicht zur Speicherung selbst verwendet werden sollte, ist der Dateiupload primär für die Anzeige von Bildern gedacht. Jeder Katalogeintrag kann beliebig viele Ressourcen besitzen, und die Zugriffsberechtigung auf Ressourcen ist deutlich strenger als bei Katalogeinträgen. So kann nicht nur zwischen öffentlich sichtbar und organisationsintern unterschieden werden, sondern auch der Zugriff auf Ressourcen auf ganz bestimmte Personengruppen beschränkt werden. Es kann demnach vorkommen, dass ein Anwender einen Katalogeintrag sehen kann, nicht jedoch die darin verlinkten Ressourcen.
Verknüpfung von Katalogeinträgen zeigt Zusammenhänge auf

In der Katalogplattform können Katalogeinträge untereinander verknüpft werden. Eine Verknüpfung ist dabei ein Link zu einem anderen Katalogeintrag. Es gibt drei verschiedene Arten von Verknüpfungen:

  1. Ein Katalogeintrag ist abhängig von einem anderen Katalogeintrag
  2. Ein Katalogeintrag ist ein Teil von einem anderen Katalogeintrag
  3. Ein Katalogeintrag weist auf einen anderen Katalogeintrag hin
Für jeden Katalogeintrag können beliebig viele verschiedene Verknüpfungen zu anderen Katalogeinträgen eingetragen werden. Bei den entsprechenden Gegenstücken, also den Einträgen, auf die sich die Verknüpfungen beziehen, erscheinen automatisch auch die Gegenstücke der Verknüpfungen. Es handelt sich demnach um zweiseitige Beziehungen.
Beispiele aus der Katalogplattform

Die Liste aller Katalogeinträge zeigt neben dem Titel und einem Ausschnitt aus der Beschreibung auch die verwendeten Ressourcen und die zugehörige Haupt-Kategorie an. Abbildung 7 zeigt zwei Einträge aus der Katalogplattform.

Abbildung 8 zeigt den BayernAtlas als einen Beispieleintrag aus der Katalogplattform. Die räumliche Ausdehnung ist auf die gesamte Fläche von Bayern festgelegt, sodass der Katalogeintrag bei jeder Suche innerhalb Bayerns erscheint.

Datensicherheit und Zugriffsrechte
Ein wichtiger Aspekt ist die Datensicherheit und das Datenmanagement. Ein jeder Benutzer im Katalog ist einer Organisation zugeordnet, und einzelne Organisationen können anderen Organisationen untergeordnet werden. Somit ist nicht nur gewährleistet, dass jeder Eintrag in der Katalogplattform automatisch der richtigen Organisation zugeordnet wird, sondern auch, dass keine organisations-fremden Katalogeinträge erstellt werden können. Ein Administrator für einen Bereich innerhalb einer Organisation kann neue Mitglieder hinzufügen, und Katalogeinträge können so konfiguriert werden, dass sie nur innerhalb der eigenen Organisation sichtbar sind.
Der Katalog als Open Source Software mit verschiedenen Erweiterungen
Für die Implementation der Katalogplattform wurde die freie Open-Source Software CKAN verwendet. Verschiedene Erweiterungen (auch Plugins genannt) helfen dabei das Aussehen anzupassen und neue Features zu implementieren. Bei den Erweiterungen handelt es sich einerseits um bereits in anderen Katalogdiensten verwendete Software-Pakete, aber auch um Eigenentwicklungen des ZD.B, welche die Funktionalität und verschiedenste Aspekte ergänzen.
Regionale Instanzen des Katalogs durch Docker-Technologie
Die Katalog-Plattform ist bayernweit hierarchisch gegliedert in mehrere Instanzen des Katalogdienstes. Es gibt zum einen einen landesweiten Datenkatalog, der Informations-Ressourcen aus sämtlichen Gebieten und (Modell)Regionen enthält. Zum anderen können smarte Städte und Regionen eine eigene Instanz dieses Katalogs aufsetzen. Der übergeordnete, landesweite Katalog ist in der Lage, Datensätze aus den regionalen Katalogen zu auszulesen und sich somit automatisch auf den aktuellen Stand zu bringen. Mit Hilfe der Docker-Technologie ist es sehr leicht möglich eine neue Instanz des Katalogs aufzusetzen, welcher als unabhängiger und (noch) leerer Katalog vorliegt. Dies erfordert lediglich eine Installation der Docker-Software auf einem Computer, welcher im Anschluss als Server für den Katalog dient. Um das Instanziieren eines Katalogs in einer Region zu vereinfachen, steht die kostenlose Katalog-Software als Docker-Container bereit. Docker ist eine Technologie zum Betrieb von Software-Paketen in Container-Form. Dies ermöglicht ohne größeren Zeit- und Programmieraufwand das Aufsetzen einer Katalogplattform, welche sämtliche Erweiterungen des Haupt-Katalogs enthält. Eine detaillierte Anleitung zur Installation dieses Docker-Containers ist zu finden unter https://github.com/tum-gis/sddi-ckan-docker.
Ein leerer Katalog kann mittels Content-Packages befüllt werden
Nach einem neuen Aufsetzen der Katalogplattform ist diese zunächst leer. Mit Hilfe von Content-Packages kann ein Grundbestand an Katalogeinträgen installiert werden, sodass der Katalog nicht komplett leer ist, sondern bereits für bestimmte Anwendungsfälle relevante Einträge enthält. Ein solches Content-Package enthält eine Liste an Katalogeinträgen, die zuvor sorgfältig ausgewählt worden sind, beispielsweise eine bestimmte thematische Zusammenstellung von Geodaten aus der GDI Bayern. Es gibt verschiedene Arten von Paketen mit verschiedenen Katalogeinträgen, von denen je nach Bedarf, eines oder mehrere installiert werden können. Im Begleitendes Wiki (https://wiki.tum.de/display/dzb) liegt eine Liste von Content-Packages, sowie eine Installationsanleitung vor.
  • Keine Stichwörter