Erklärungen zum Aufbau

Im Folgenden wird das Vorgehen beim Aufbau einer Dateninfrastruktur nach der SDDI-Methode beschrieben. Dabei wird zunächst der theoretische Hintergrund auf der Basis einer ISO-Norm beleuchtet. Es folgen ein Vorschlag für die Definition von Rollen für die Akteure der Dateninfrastruktur und schließlich ein konkretes Beispiel für den Prozess zum Aufbau einer SDDI in einer Pilotregion.

Vorausgesetzt wird, dass von Beginn an eine zentrale Katalogplattform als Wissensbasis für die einzelnen Schritte des Aufbaus einer SDDI zur Verfügung steht. Eine Anleitung zum Aufsetzen einer solchen Katalogplattform basierend auf der CKAN-Technologie ist im Begleitendes Wiki (https://wiki.tum.de/display/dzb) zu finden. Die Installation kann zum einen als direkte Installation, aber auch mittels der Docker-Technologie erfolgen.

Open Distributed Processing als Herangehensweise

Arbeitsteilung nach Open Distributed Processing
Für den Aufbau einer verteilten Dateninfrastruktur für Projekte in Smarten Städten und Regionen wurde im Zuge des bereits erwähnten Projekts SSD der ISO Standard 10746 „Information technology — Open Distributed Processing – Reference Model (ODP-RM)“ adaptiert und erfolgreich eingesetzt. Diese Norm beschreibt einen Ansatz zur Standardisierung von gemeinsam genutzten und offenen Prozessschritten und stellt damit eine Anleitung parat mit deren Hilfe komplexe Aufgaben mit verschiedenen Akteuren angegangen werden können. Das Modell kann unter anderem dabei eingesetzt werden plattformunabhängige, übertragbare und offene Systeme wie die SDDI aufzubauen und einen Gesamtüberblick über die Herausforderungen in einem Stadtteil, einer Kommune oder Region oder in einem bestimmten Projekt zu verschaffen. Mittels Open Distributed Processing können unter anderem auch die Verantwortlichen und deren verschiedenen Aufgaben erarbeitet werden, da eine einzelne Person oftmals nicht die nötige Expertise und die Zeit besitzt, um jeden einzelnen Schritt durchführen zu können. Somit kann an den verschiedenen Bedarfspunkten in einem Projekt gezielt gearbeitet werden. Die verschiedenen Interessen, Bedarfe und Ressourcen der einzelnen Akteure können durch diese Herangehensweise als zentrale Ausgangsbasis verwendet werden, um daraus in Folge geeignete technisch-organisatorischen Lösungen zu generieren, und sich nicht direkt auf die technische Realisierung stürzen zu müssen.
Fünf Sichtweisen auf ein Projekt

Das Modell besteht aus fünf verschiedenen Sichtweisen auf ein Projekt, welche sich untereinander beeinflussen. Jede dieser Sichtweisen spiegelt einen Planungsschritt wider und zielt auf einen anderen Aspekt in der Planungskette ab. Nach dem ISO 10746 Standard gibt es die folgenden Sichtweisen auf ein System: Enterprise viewpoint, Information viewpoint, Computational viewpoint, Engineering viewpoint und Technology viewpoint. Sie können dabei in verschiedener Reihenfolge behandelt werden, es wird folgendes Ablaufschema (Abbildung 9) vorgeschlagen:

Schritt 1: Ziel des Projektes finden

1)   Der „Enterprise Viewpoint“, auch „Unternehmenssicht“ genannt, zielt darauf ab die beteiligten Parteien und Interessenvertreter zu verstehen und ihre Rollen und Interessen einschätzen zu können. Die Informationen hierzu können großteils bereits von SDDI-Readiness übernommen werden und werden im Enterprise Viewpoint konkretisiert. Die „Unternehmenssicht“ konzentriert sich auf Zweck, Umfang und Richtlinien des Projekts. Sie beschreibt die geschäftlichen Anforderungen und Möglichkeiten, die nötig sind, um diese zu erfüllen. Die "Unternehmenssicht" spielt eine entscheidende Rolle, da sie die Richtung der anderen Schritte definiert.

Schritt 2: Datenstruktur festlegen
2)   Im zweiten Schritt wird das System aus drei verschiedenen Blickwinkeln betrachtet: Der „Information Viewpoint“, auch „Informationssicht“ genannt, konzentriert sich auf die Datenmodellierung und die Semantik der zu verwaltenden Informationen. Sie definiert Ontologien, also Beziehungen zwischen bestimmten Bereichen, die durch Datenmodelle und deren semantische Definitionen spezifiziert sind. In der SDDI werden beispielsweise spezifische Datenmodelle für Sensorbeschreibungen, Sensorbeobachtungen und das 3D-Stadtmodell verwendet. Die „Computational View“ beschreibt sowohl die Prozesse als auch die Daten- und Kontrollflüsse. Hier wird spezifiziert, wie die Benutzeraufgaben (und damit der in der Unternehmenssicht definierte Zweck des Gesamtsystems) mit den in der Informations- und Engineering-Sicht spezifizierten Entitäten und Konzepten realisiert werden können. Die „Engineering View“ zeigt, wie die Informationsinfrastruktur aus modularen, verteilten Elementen aufgebaut werden kann. In diesem Fall schließt dies die Entscheidung ein, eine serviceorientierte Architektur (SOA) unter Verwendung von standardisierten, offenen Web-Service-Schnittstellen- und Protokolldefinitionen, zum Beispiel des Open Geospatial Consortium (OGC), zu verwenden.
Schritt 3: Konkrete Implementierung planen
3)   Im dritten und letzten Schritt wird das System aus der technischen und implementierungstechnischen Perspektive, d.h. der „Technology View“, betrachtet. Hier werden geeignete Software- und Hardwareprodukte ausgewählt und deren Konfiguration sowie die Implementierung des Systems geplant und beschrieben.

Vorgehensweise anhand eines Beispiels

Vorgehen am Beispiel

Die verschiedenen Viewpoints werden im Folgenden anhand eines fiktiven Projekts im Detail erklärt. Im ersten Abschnitt eines Projekts zum Aufbau einer Dateninfrastruktur für Smarte Städte und Regionen wurden von einer Stadt die folgenden Herausforderungen identifiziert: Nutzung erneuerbarer Energien fördern und Klima-Resilienz stärken. Im Rahmen eines Stadtumbauprojekts wurden daher zwei Use Cases definiert:

  • Nutzung von Solarenergie für einen geplanten Gebäudekomplex der Stadtverwaltung. Es soll mittels digitaler Modelle verschiedener Varianten des geplanten Gebäudekomplexes diejenige ermittelt werden, die den besten Kompromiss aus Kosten und erzeugter Solarenergie darstellt. Die für diesen Use Case zu entwickelnde Dateninfrastruktur soll langfristig für alle Bauvorhaben im Stadtgebiet genutzt werden können.
  • Entwicklung von Plänen für eine grünere, attraktivere und klimaresiliente Innenstadt. Es soll mittels digitaler Modelle eines geplanten Gebäudekomplexes diejenige Variante ermittelt werden, die aus Sicht des Stadtklimas (d.h. Vermeidung von Hitzeinseln, hohe Aufenthaltsqualität für Passanten, Kühlung der Gebäude und ihrer direkten Umgebung bis hin zur Nahrungsmittelproduktion auf den Dächern) den besten Kompromiss darstellt.

Für beide Use-Cases soll die Umgebung des geplanten Gebäudekomplexes in die Untersuchungen einbezogen werden. Abbildung 10 zeigt die Struktur des geplanten Projekts und die beiden geplanten Use Cases mitsamt ihren benötigten Daten und erwarteten Ergebnissen.

In Workshops mit den Akteuren wurden im ersten Schritt die unter dem Kapitel 2. erwähnten Kriterien erarbeitet. Die folgenden Abschnitte beschreiben nun das Vorgehen zum Aufbau der Dateninfrastruktur innerhalb der einzelnen Viewpoints.

Enterprise Viewpoint

Der Enterprise Viewpoint dient der Integration der Anforderungen verschiedener Akteure

Bei der Implementierung der SDDI werden im Enterprise Viewpoint (Unternehmenssicht) folgende Schritte durchlaufen:

  1. Für jeden Use Case wird ein “Pate” festgelegt (siehe Abschnitt „Akteure und ihre Rollen“), der in Abstimmung mit dem Gesamtprojektleiter die Entwicklung des Use Case vorantreibt und steuert.
  2. Vorbereitung eines Workshops zu den technischen Anforderungen und den Anforderungen an die Daten für die Use Cases. Hierzu zählt auch das Identifizieren der Akteure, die für die Umsetzung des Use Case wichtig sind. In dieser Phase dient die Katalogplattform dem „Paten“, dem Gesamtprojektleiter und dem Experten für Datenintegration der Recherche nach im Gesamtprojekt bereits vorhanden Informations-Ressourcen und der Katalogisierung bereits in dieser Phase bekannter Informationen (z.B. „es gibt für die Region bereits ein 3D-Modell“).
  3. Durchführung des Workshops mit den in 2. identifizierten Akteuren, einschließlich Experten für Datenintegration, welche ihr Wissen zur Verfügung stellen. Die SDDI, sowie dieser Leitfaden, beziehen sich dabei vorrangig auf die Datenintegration, und nicht auf andere Aspekte wie domänenspezifische Aspekte oder Interessenskonflikte zwischen Parteien.
  4. Zusammenfassung der Workshop-Ergebnisse in tabellarischer Form, ggf. Aktualisierung der Liste der Akteure in Abstimmung mit dem Gesamtprojektleiter
  5. Eintragen der relevanten Informationen in die zentrale Katalogplattform
Damit stehen für jeden Use Case die Akteure, die benötigten Daten und ihre Bezugsquellen, die Urbanen Analysewerkzeuge, etc. fest.

Akteure und ihre Rollen

Einschätzung und Auswahl von Akteuren für den weiteren Prozess mit Hilfe der Stakeholder-Matrix

Um die verschiedenen Akteure besser einordnen zu können empfiehlt sich die Verwendung einer Stakeholder-Matrix. Diese ist in den SSD-Regionen bereits zum Einsatz gekommen und hat sich als sinnvolles Hilfsmittel bewährt. Die Stakeholder-Matrix ist ein 2-Achsen-Diagramm mit dem bekundeten Interesse eines Akteurs auf der horizontalen Achse und seinem Einfluss auf das Projekt in der vertikalen Achse. Jeder Stakeholder wird nun entsprechend seiner Involviertheit in diesem Diagramm frei platziert, je nachdem wie stark oder schwach seine Zugehörigkeit zu den beiden Achsen des Diagramms ist. Im Anschluss können die Stakeholder nun in vier Kategorien unterteilt werden:

  • Zufrieden halten: Stakeholder mit generell wenig Interesse aber hohem Einfluss, z.B. die Eigentümer wichtiger Daten für das Projekt, sollten gut mit Informationen über den Fortgang des Projekts versorgt und zufrieden gehalten werden, da viel von ihnen abhängt. Dies kann zum Beispiel geschehen, in dem der Nutzen des Use Case für sie transparent gemacht und ihr Beitrag zum Use Case öffentlichkeitswirksam dargestellt wird.
  • Stark zusammenarbeiten: Stakeholder die sowohl viel Einfluss als auch großes Interesse an einem Projekt haben sind die stärksten Partner. Mit ihnen ist eine enge Zusammenarbeit unabdingbar. Bei einer Steigerung der Attraktivität des ÖPNV-Netzes wären dies z.B. der ÖPNV-Netzbetreiber selbst oder Telekommunikationsanbieter.
  • Im Auge behalten: Akteure mit geringem Interesse und Einfluss erweisen sich kurzfristig gesehen vielleicht nicht als großer Gewinn, bringen zu einem späteren Zeitpunkt jedoch vielleicht neue Ideen ein oder gewinnen an Relevanz, wenn es zu neuen Entwicklungen kommt. Sie sollten während der Planung und Umsetzung im Auge behalten werden. Als Beispiel dienen hier Bürger aus anderen Gemeinden oder kleinere Dienstleister, welche nur am Rande in das Projekt involviert sind.
  • Informiert halten: Stakeholder mit viel Interesse aber wenig Einfluss, z.B. Anwohner, sollten über die weiteren Schritte informiert bleiben, um ihre Interessen und Anregungen vorbringen zu können.

Verschiedene Rollen bei den Akteuren sollten klar definiert sein

Neben der Einteilung der Akteure nach Einfluss und Interesse an einem bestimmten Use Case ist auch eine Festlegung von Rollen für die tatsächliche Umsetzung eines Use Case sehr hilfreich. Die Akteure nehmen dabei im Gesamtprojekt und in den Use Cases unterschiedliche Rollen ein. Ein und derselbe Akteur kann so in verschiedenen Rollen im Gesamtprojekt und in den einzelnen Use Cases auftreten Abbildung 12 stellt diesen Zusammenhang in vereinfachter Form anhand des Beispiel-Projekts dar.

Um sicherzugehen, dass jede Rolle in der Umsetzung eines Projektes mit mindestens einem Stakeholder besetzt ist, empfiehlt es sich für jeden Use Case die vorhandenen Rollen aufzulisten und die vorhandenen Akteure darauf aufzuteilen. Um eine SDDI-Instanz umsetzen zu können, werden im SDDI-Prozess folgende Rollen besetzt. Es kann dabei zwischen Use-Case-unabhängigen Rollen und Use-Case-spezifischen Rollen unterschieden werden:

  • Rollen für das Bereitstellen der zentralen Dateninfrastruktur:
    • Fachlicher Experte für Datenintegration: Der fachliche Experte für  Datenintegration hat einen Überblick über alle im Gesamtprojekt  verwendeten Daten und über standardisierte Datenmodelle.
    • Projektleiter: Treiber des Gesamtprozesses der Umsetzung
    • Mentor: Entscheidungsträger in der Gebietskörperschaft, der das Tun des Projektleiters auf strategischer Ebene / politisch unterstützt
    • Basisdatenlieferant für das virtuelle Distriktmodell: Zur Umsetzung und zur Aktualisierung des -->Virtuellen Distriktmodells werden Basisdaten benötigt, zum Beispiel 3D-Gebäudemodelle und ein Digitales Geländemodell. Anbieter dieser Daten ist meist die zuständige Geodatenverwaltung.
    • Betreiber des virtuellen Distriktmodells: Neben den Basisdaten und den spezifischen Fachdaten des Use Cases benötigt das virtuelle Distriktmodell auch eine Person oder einen Dienstleister,  von dem das Hosting inkl. Einspielen von aktualisierten Daten übernommen wird. Dies erfordert meist den Betrieb eines (3D-)GIS bzw. einer Geodatenbank mit entsprechendem Datenmodell und entsprechenden offenen, standardisierten Schnittstellen.
    • Betreiber und Redakteure des Geovisualisierungsplattform: Die Geovisualisierungsplattform dient der Visualisierung und Exploration des virtuellen Distriktmodells. Während der Betreiber für die Bereitstellung und den Betrieb der Visualisierungsplattform zuständig ist, konfiguriert der Redakteur die Plattform so, dass sie die für die Use-Cases benötigten Inhalte visualisiert werden können.
    • Betreiber und Redakteure der Katalogplattform: Die zentrale Katalogplattform muss von einem Akteur bzw. Dienstleister betrieben werden[1]. Ebenfalls bedarf es Personen mit Erfahrung in der Bedienung des Katalogs (hier „Redakteure“ genannt), um dem Use Case entsprechend Einträge vorzunehmen und Akteuren beim Eintragen ihrer Informations-Ressourcen zu unterstützen.
    • Fachlicher Experte für Sensoren / IoT: Der fachliche Experte für  Sensoren / IoT bringt Expertise im Bereich Sensoren / IoT /  Sensordatenplattformen und -Schnittstellen ein.
    • Fachlicher Experte für Interoperabilität und verteilten Systeme: Für die Verknüpfung verschiedener Systeme wird gegebenenfalls  ein eigener Experte benötigt. Dieser kümmert sich darum, dass die  einzelnen Komponenten des Projekts auf technischer Ebene, im  SDDI-Kontext also auf der Ebene von Web Services, miteinander reibungslos kommunizieren können.
  • Use Case spezifische Rollen:
    • Anwender: Der Anwender ist eine Person, die eine SDDI-Anwendung nutzt und Nutzen daraus zieht.
    • Entwickler der Anwendung / App: Für die Entwicklung einer Use Case spezifischen Anwendung, zum Beispiel einer Smartphone-App, wird ein entsprechender Entwickler benötigt. Dies kann entweder eine Einzelperson oder ein externer Dienstleister sein
    • Lieferant von urbanen Analysewerkzeugen: Der Lieferant von  urbanen Analysewerkzeugen ist meist ein externer  Softwareanbieter, der bestimmte, für den Use Case relevante,  Werkzeuge bereitstellt. Dabei muss es sich nicht zwingend um  Software handeln, sondern es kann z.B. kann auch eine bestimmte  Methode zur Einbindung der Bevölkerung ein wertvolles urbanes  Analysewerkzeug sein.
    • Lieferant von Use-Case-spezifischen IoT-Sensordaten: die Person, die zuständig ist für die Bereitstellung von IoT oder Sensordaten.
    • „Pate“ des Use Cases: In jedem Use Case wird ein sogenannter „Pate“ (Use Case Owner) benötigt, der die Organisation übernimmt und für einen reibungslosen Ablauf sorgt. Der Pate muss selbst kein Experte auf jedem einzelnen Teilgebiet sein, das von dem Use Case tangiert wird, sollte jedoch genug Vorwissen mitbringen, um einen Überblick über alle Teilbereiche eines Projekts zu erlangen.
    • Fachlicher Experte für den Use Case: Der fachliche Experte für den Use Case kann sowohl ein eine Person mit entsprechendem Knowhow als auch ein externer Berater sein. Wichtig ist ein umfassendes Wissen im Bereich des Projekts, hierfür können auch mehrere Personen in einem Expertenkreis zusammengefasst werden.
    • Lieferant von Use Case spezifischen statischen Domänendaten: Neben den  genannten Basisdaten sind oft spezifische Daten für einzelne Use  Cases erforderlich. Dies könnten zum Beispiel Daten über  Versorgungsnetze, ÖPNV-Verkehrsnetze oder Anwohnerdaten sein. Diese Informationen können mit dem virtuellen Distriktmodell verknüpft werden, um dessen anzureichern.

Für jede einzelne dieser Rollen sollte eine Stakeholder-Matrix aufgesetzt und mit den verschiedenen Stakeholdern befüllt werden. Somit entstehen verschiedene Diagramme, welche die verschiedenen Interessens- und Einflusslagen der Akteure widerspiegeln. Es ist dabei möglich, dass ein Stakeholder in einer der Rollen starkes Interesse zeigt, in einer anderen jedoch nur geringes oder andersherum. Die Ergebnisse können in einer gemeinsamen Tabelle kombiniert werden, und so übersichtlich darstellen welche Personen, Dienstleister, Behörden, usw. in welcher Art an dem Use Case mitwirken.


[1] im Rahmen der ZD.B-Themenplattform „Smart Cities and Regions“ wird eine Katalogplattform („Masterkatalog“) zentral gehostet und bayernweit zur Verfügung gestellt. Für regionale Kataloginstanzen wird eigene Hardware sowie eine zuständige Person oder ein Dienstleister benötigt.

Der Enterprise Viewpoint am Beispiel

Ein Beispiel für den Enterprise Viewpoint

Für den Use Case (A) ergab sich im Zuge des Abschnitts 1 (SDDI-Readiness) die folgende Stakeholder-Matrix. Als erster Schritt im Rahmen des Enterprise Viewpoint wurden vom Gesamtprojektleiter anhand der Matrix und in Gesprächen mit den potenziellen Stakeholdern diejenigen identifiziert, die für die Umsetzung des Use Case wichtig sind (in Abbildung 12 rot markiert). Im Zuge dessen wurde auch der “Pate” (Use Case Owner) für den Use Case bestimmt (in Abbildung 12 grün markiert).

In einem anschließenden Workshop mit den ausgewählten Akteuren wurden die technischen Anforderungen und die Anforderungen an die Daten erarbeitet. Die SDDI, sowie dieser Leitfaden beinhaltet dabei ausschließlich Aspekte der Datenintegration, und nicht andere domänenspezifischen Aspekte, wie zum Beispiel Energieversorgung oder Mobilität.

Für benötigte Daten können Bezugsquellen mit Hilfe einer Tabelle ermittelt werden

Im Workshop entstanden die folgenden Tabellen, die für jeden Use Case die erforderlichen Informations-Ressourcen und die möglichen Bezugsquellen enthalten. Dabei wurde in der zentralen Katalogplattform recherchiert ob diese Informations-Ressourcen im Gesamtprojekt bereits an anderer Stelle genutzt werden. Im Workshop wurden auch alle Konflikte und Probleme bei der Bereitstellung der Daten identifiziert und dokumentiert. Mögliche Alternativen zur Konfliktlösung wurden ebenfalls erörtert. Für Use Case (A) ergaben sich die folgenden Tabellen, mit dem Ziel, das Solarpotenzial für die verschiedenen Gebäudevarianten zu ermitteln. Das Solarpotenzial wird mit zwei Urbanen Analysewerkzeugen ermittelt. Werkzeug 1 schätzt die solare Einstrahlungsenergie, Werkzeug 2 berechnet daraus den potenziellen Strom-Ertrag unter Berücksichtigung der Spezifikation unterschiedlicher Photovoltaik-Module. Beispielhaft stellt Tabelle 1 die benötigten Daten für Werkzeug 1 den Bezugsquellen gegenüber. Mit Symbolen wird die Verfügbarkeit der Daten näher beschrieben. So wird mit ( ) angezeigt, dass die Daten verfügbar sind und (!) deutet an, dass es im Anschluss an den Workshop noch Klärungsbedarf gibt. (x) bedeutet, dass benötigte Daten nicht verfügbar sind. Ein Muster für eine derartige Tabelle befindet sich im Anhang.

Nachdem die benötigten Informations-Ressourcen (im Beispiel die benötigten Daten und Urbanen Analysewerkzeuge) feststehen, aktualisiert der Datenintegrationsexperte zusammen mit dem “Paten” des Use Case in Abstimmung mit dem Gesamtprojektleiter die folgenden Informationen (zum Beispiel wird die Vermessungsverwaltung als wichtiger Datenbereitsteller für den Use Case in die Liste der Akteure aufgenommen) und fasst sie in einer weiteren Tabelle zusammen (Vorlage siehe Anhang):

  • Beteiligte Akteure und deren Rollen mit Ansprechpersonen
  • Verfügbarkeit von Daten und Werkzeugen

Als letzter Schritt im Rahmen des Enterprise Viewpoint, werden grundlegende Informationen in die Katalogplattform (siehe Kapitel „Der Katalogdienst – Die zentrale Plattform für alle Informations-Ressourcen“) des Projekts eingetragen. Dies kann zum Beispiel durch den Datenintegrationsexperten, oder durch die jeweiligen Bereitsteller der Informations-Ressourcen erfolgen.

Information Viewpoint / Engineering Viewpoint / Computational Viewpoint

Bestehende, standardisierte Datenmodelle erleichtern eine Integration der Daten

In einem ersten Schritt wird das Datenmodell des Virtuellen Distriktmodells festgelegt. Das ist entscheidend, um in weiteren Schritten die Verknüpfungen zwischen den Objekten des Distriktmodells und weiteren, Use-Case-spezifischen Daten definieren zu können. Im Projekt SSD hat sich CityGML als Datenmodell für das Virtuelle Distriktmodell bewährt, unter anderem, weil es die reale Welt in dreidimensionale, semantische Objekte zerlegt und bereits Möglichkeiten zur anwendungsspezifischen Modellerweiterung, zur Verlinkung mit weiteren Daten sowie zur semantischen Anreicherung der Objekte vorsieht.

Im nächsten Schritt werden die für den Use Case benötigten Daten dem Datenmodell des VDM gegenübergestellt und soweit sinnvoll ein semantisches Mapping zwischen dem Datenmodell des VDM und den Modellen der benötigten Daten definiert. Um das semantische Mapping umzusetzen, ist es ggf. erforderlich Konvertierungsregeln zu erarbeiten (z.B. Regeln für die Überführung eines vom Architekten erzeugten Architekturmodells eines Gebäudes in das Datenmodell von CityGML).

Da nicht alle Fach- und Sensordaten durch ein Datenmodell beschrieben sind, können ggf. Datenmodelle im rerverse Engineering aus den vorhandenen Daten (z.B. Excel- oder CSV-Daten) erzeugt werden.

Ergebnis des Information Viewpoint ist eine Zusammenstellung der für den Use Case benötigten Daten in der richtigen Struktur, so dass sie miteinander verknüpft werden können.

Der Information Viewpoint am Beispiel

Für den Use Case (A) aus unserem Beispiel entstand unter anderem die folgende Tabelle:

Aufgaben im Computational Viewpoint

Der Computational Viewpoint beschreibt Daten- und Kontrollflüsse
Im Computational Viewpoint werden alle Daten und Kontrollflüsse für das Zusammenwirken der verteilten Systemkomponenten der SDDI analysiert und beschrieben. Als Ergebnis sollte eine Strategie vorliegen, mit der ausgehend von den Eingangsdaten und Modellen das im Vorfeld definierte Ziel des Use Cases erreicht werden kann.

Der Computational Viewpoint am Beispiel

Indentifikation von Systemkomponenten und Prozessierungsschritten und Datenflüssen

Ausgehend von den fünf Eingangsdatenquellen, welche im Kapitel „Der Enterprise Viewpoint am Beispiel“ festgelegt wurden, soll ein anwenderfreundlicher 3D Web Map Client entstehen, der das Geländemodell, die Vegetation, die Bestandsgebäude, sowie die berechneten Solarwerte für Dachflächen geplanter Gebäude aufzeigt. Der 3D Web Map Client soll die Funktionalität bieten, ein geplantes Gebäude zu laden (ggf. bestehende Gebäude am Ort des geplanten Gebäudes auszublenden) und die Solarpotentialanalyse für das geplante Gebäude anzustoßen. Hierfür wurden die in der Abbildung 13 als blaue Kästchen dargestellten Systemkomponenten identifiziert. Die ockerfarbenen Kästchen zeigen Prozessierungsschritte auf, die grünen Pfeile verbinden die Systemkomponenten. Die Darstellung erfolgt auf konzeptueller Ebene. Das heißt, dass die Systemkomponenten unabhängig von einem bestimmten Softwareprodukt beschrieben werden. Fest stehen an dieser Stelle lediglich die im Information Viewpoint definierten Datenmodelle (im Beispiel CityGML für das VDM und Observations&Measurements für die Wetterdaten).

Aufgaben im Engineering Viewpoint

Der Engineering Viewpoint beschreibt den Aufbau der Dateninfrastruktur

Im Engineering Viewpoint müssen nun die im Computational Viewpoint identifizierten Systemkomponenten und Datenflüssen auf eine verteilte Informationsinfrastruktur abgebildet werden, d.h. unter anderem, dass Schnittstellen zwischen den Komponenten definiert werden müssen.

Das SDDI setzt hier auf standardisierte, offene Web Service Schnittstellen. Vorhandene Systemkomponenten bieten diese Schnittstellen entweder direkt an, oder müssen mit Wrappern gekapselt werden. Dies wird beispielhaft anhand des Themas Sensordatenintegration im Folgenden erklärt.
Die Verknüpfung von Sensordaten ist ein zentraler Aspekt in der SDDI
In der SDDI spielt die Verknüpfung von verschiedenen IoT- und Sensordaten eine zentrale Rolle. Viele große Akteure wie Google, Amazon, Microsoft und IBM bieten die Cloud-basierte Speicherung, Verwaltung und Analyse von Sensordaten an, aber jeder von ihnen bietet seine eigene API an. Darüber hinaus bieten viele kleinere Unternehmen und Initiativen im IoT-Bereich wie Thingspeak und OpenSensors ähnliche Funktionalitäten an, wiederum mit eigenen APIs und unterschiedlichen Ebenen von Analysefähigkeiten. Im SSD-Projekt wurde eine leichtgewichtige Open-Source-Software namens "InterSensor Service" entwickelt und implementiert, die Anwendungsentwicklern die standardisierten APIs bietet, die im "Sensor Web Enablement" (OGC SWE) des Open Geospatial Consortium definiert sind, und die mit vielen verschiedenen proprietären APIs wie IBM WUnderground, Thingspeak, OpenSensors, aber auch mit einfachen relationalen Datenbanken und sogar Tabellenkalkulationen (die in lokalen Dateien gespeicherte tabellarische Daten als virtuelle Sensorbeobachtungen zugänglich machen) verbunden ist. Da der InterSensor Service quelloffen ist, können weitere Schnittstellen zu proprietären offenen APIs leicht hinzugefügt werden (in der Regel mit einem Tag Implementierungszeit).

Der Engineering Viewpoint am Beispiel

Für den Use Case (A) entstand das folgende Diagramm, welches hier Ausschnitthaft dargestellt wird:

Ziel des Engineering Viewpoints ist es zu dem im vorherigen Schritt entstandenen Use Case Modell in den einzelnen Komponenten die richtigen (Web-Service) Schnittstellen zu finden, um so Interoperabilität zu ermöglichen. Wo immer möglich sollte bei der Wahl der Schnittstellen auf internationale Standards zurückgegriffen werden. Im Beispiel handelt es sich hierbei um den Sensor Observation Service (SOS), sowie um die Web Map Service (WMS) und die transactional Web Feature Service (WFS-T) Schnittstelle.

Technology Viewpoint

Auswahl von Software und Hardware

Auswahl von Software und Hardware
Verschiedene Use Cases haben verschiedene Anforderungen an die eingesetzten Software- und Hardwarekomponenten. Neben Datensammlungen und Web-Anwendungen können auch mobile Anwendungen eine entscheidende Rolle haben. In den meisten Use Cases wird jedoch hauptsächlich ein Online-Dienst benötigt, welcher relevante Daten an verschiedene Clients liefert. Das Grundgerüst besteht in diesem Fall aus einer Datenbank sowie einer API-Schnittstelle, welche mittels offener Standards angesprochen werden kann.

Der Technology Viewpoint anhand des Beispiels


Die benötigte Hardware und Software ist gefunden und die Implementierung des Use Case kann begonnen werden

Im Technology Viewpoint werden die benötigten Hardware- und Software Komponenten für die Umsetzung des Use Cases ermittelt. Abbildung 16 zeigt die technische Umsetzung des im Kapitel „Der Computational Viewpoint am Beispiel“ aufgezeigten Arbeitsflusses in einem kleineren Ausschnitt. In Rot sind die neuen Komponenten markiert. Sämtliche Transformationen der ursprünglichen Daten in CityGML konforme Datenmodelle erfolgen in unserem Beispiel mittels der Software FME. Die Open Source Software 3DCityDB zur Verwaltung des Virtuellen Distriktmodells wird von einem Dienstleister aufgesetzt und verwaltet. Ein Hochleistungsrechner des Experten für Solarpotentialanalysen übernimmt die Berechnung der Sonneneinstrahlungswerte auf die jeweiligen Dachflächen und reichert die Objekte in der 3DCityDB über die WFS-T-Schnittstelle mit den Berechnungsergebnissen an. Anschließend werden die konkreten Instanzen der Systemkomponenten (z.B. Web Feature Service für den Zugriff auf das Virtuelle Distriktmodell mit Web-Adresse unter der dieser Dienst erreichbar ist) in die Katalogplattform eingetragen, um sie für das Gesamtprojekt und darüber hinaus sichtbar zu machen. Da an dieser Stelle alle benötigten Systemkomponenten und ihre Schnittstellen bekannt sind, eignen sich vorliegenden Ergebnisse des SDDI-Prozesses auch zur Erstellung von Ausschreibungsunterlagen für die Implementierung des Use Case. Da die verschiedenen Use Cases in einem Projekt auf die gleichen Ressourcen und ähnliche Prozesschritte zurückgreifen können, ist es oft sinnvoll sämtliche Komponenten eines Projekts zeitgleich zu betrachten.

  • Keine Stichwörter