Currently, in environmental systems, and disaster management in particular, we are witnessing a general shift from isolated monolithic implementations to highly robust and functionally distributed information processing in a systems of systems approach. Warning systems can serve as a representative example of a class of applications where these new requirements can be observed. Currently, warning systems are primarily specific developments with a generally similar but custom-made and often monolithic architecture. In order to meet the new challenges, appropriate reference architectures for these types of system classes are required to prevent a complete reimplementation of each new system. This paper presents a reference architecture for warning systems developed and tested in the basis of the KATWARN warning systems. The approach has been tested in a wide range of applications, ranging from mass application of a public warning system with approximately 4 million users in Germany and Austria to local target group-specific warning systems for critical infrastructures and large chemical plants. Based on the principles of event-based and asynchronous architecture paradigms, the implementation is described in a Microservice-based reference architecture. The architecture shows how challenging requirements in regards to performance, robustness and scalability can be met in such distributed process environments.
Derzeit erleben wir in Umweltsystemen und insbesondere im Katastrophenmanagement einen generellen Wandel von isolierten monolithischen Implementierungen hin zu hochgradig robuster, verteilter Funktionalität und Informationsverarbeitungsketten in einem „Systems of Systems“-Ansatz. Warnsysteme können als repräsentatives Beispiel für eine Klasse von Anwendungen dienen, in denen diese neuen Anforderungen beobachtet werden können. Derzeit sind Warnsysteme hauptsächlich spezifische Entwicklungen mit einer im Allgemeinen ähnlichen, aber einzelangefertigten und oft monolithischen Architektur. Um den neuen Herausforderungen gerecht zu werden, sind entsprechende Referenzarchitekturen für diese Art von Systemklassen notwendig, um eine komplette Neukonzeption bei jeder neuen Implementierung zu verhindern. Dieser Beitrag stellt eine Referenzarchitektur für Warnsysteme vor, die auf der Grundlage mehrjähriger Forschung entwickelt und in den KATWARN-Warnsystemen getestet wurde. Der Ansatz wurde in einem breiten Anwendungsfeld getestet, von der Massenanwendung eines Bevölkerungswarnsystems mit ca. 4 Millionen Nutzern in Deutschland und Österreich bis hin zu lokalen zielgruppenspezifischen Warnsystemen für kritische Infrastrukturen und große Chemieanlagen. Basierend auf den Grundlagen von ereignisbasierten und asynchronen Architekturparadigmen wird die Implementierung in einer Mikroservice-basierten Referenzarchitektur beschrieben. Die Architektur zeigt, wie damit hohe Anforderungen an Performanz, Robustheit und Skalierbarkeit in verteilten Prozessumgebungen erfüllt werden.
Mit der stark wachsenden Verfügbarkeit von (Echtzeit-)Sensordaten und der nahezu
ubiquitären Verbreitung von mobilen Geräten wurden im Bereich Monitoring und
Dissemination im vergangen Jahrzehnt die entscheidenden Voraussetzungen für die
Realisierung effektiver Warnsysteme für verschiedenste Einsatzbereiche und
Zielgruppen geschaffen [
Mit diesem breiten Einsatzspektrum und neuen technischen Anbindungsmöglichkeiten
im Bereich Internet of Things (IoT) steigen sowohl die funktionalen aber auch
insbesondere die nicht-funktionalen Anforderungen an die technische Realisierung
derartiger Warnsysteme. Im funktionalen Bereich sind dies beispielsweise die situative
sowie zielgruppenspezifische Anpassung von Warnnachrichten und
Verhaltenshinweisen oder die Erweiterung durch Crowdsensing-Elemente wie
Tasking- und Rückmeldungsfunktionen [
Der vorliegende Beitrag stellt eine Referenzarchitektur vor, die auf Basis langjähriger
Forschungsarbeiten entwickelt und in dem Warnsystem KATWARN [
Das hier betrachtete Anwendungsfeld ist ein Teilgebiet von Frühwarnsystemen Vereinfachend umfassen die funktionalen Komponenten einer vollständigen Frühwarnsystemimplementierung Monitoring, Entscheidungsunterstützung (d. H. Gefahrenerkennung, Risikobewertung) und reine Warnsysteme. Die Ziele eines Monitoring-Systems sind die laufende Überwachung gegebener Indikatoren durch Messungen (üblicherweise durch physikalische Sensoren, virtuelle Sensoren oder Sensorsysteme) bzw. Schätzungen in einer gegebenen Frequenz, um die gewonnenen Daten bereitzustellen. Ziel des Gefahrenerkennungssystems ist es, Gefährdungsgefahren zu erkennen und die daraus resultierenden Gefahrensituationen abzuschätzen, die beide auf der Analyse verfügbarer Beobachtungsinformationen beruhen. Ziel eines Risikobewertungssystems ist es, Risiken im Zusammenhang mit einer bestimmten Gefährdungslage zu bewerten. Schließlich ist das eigentliche Warnsystem für die Generierung von gezielten Warnungen aus den erkannten Gefahren- und Risikoinformationen sowie für deren effiziente Verbreitung verantwortlich.
Im Folgenden konzentrieren wir uns auf die Gruppe der Warnsysteme, die auch als Alarmierungssysteme bezeichnet werden. Wir sollten jedoch den allgemeinen Kontext von Früharnsystemen berücksichtigen, da Warn- oder Alarmietrungssysteme immer Teil des gesamten Frühwarnsystems sind. Dies wird insbesondere wichtig, wenn wir die nicht-funktionalen Anforderungen wie Interoperabilität oder Flexibilität diskutieren. Zum Beispiel muss in einem Frühwarnsystem für mehrere Gefahrenarten (multi212 hazard) ein Warnsystem an mehrere Überwachungs-, Gefahrenerkennungs- und Risikobewertungssysteme anschließbar sein.
Mit den Möglichkeiten neuerer Informationstechnologien und -infrastrukturen
hinsichtlich Sensorik, Rechenleistung, durchgängiger Vernetzung sowie
Informationsverbreitung erleben wir seit den frühen 2000er Jahren eine Entwicklung
von neuen Frühwarnsystemen vor allem im Bereich von Naturgefahren wie
Extremwetter, Erdbeben oder Tsunamis. Ein erster Versuch, die Architektur von EWS
allgemein zu strukturieren und wiederverwendbare Komponenten bereitzustellen,
wurde im Rahmen des Projekts ASGARD zwischen 2002 und 2004 von der Joint
Reseerch Center durchgeführt [
Wie jedoch in einer Analyse von bestehenden Frühwarnsysteme [
In unseren Forschungsarbeiten, die mit Referenzarchitekturen auf Basis klassischer,
datenbankzentrierter, schichten- und serviceorientierter Architekturen begannen,
mussten wir feststellen, dass derartige Ansätze ihre Grenzen nicht so sehr in
funktionalen, sondern vor allem in nicht-funktionalen Anforderungen haben,
insbesondere wenn es zu Leistungs- und Skalierbarkeitsanforderungen in
Massenanwendungen kommt (z. B. zeitkritische Warnungen für mehr als 1 Mill.
Benutzer). Daher haben wir in den letzten fünf Jahren unsere bestehende
Referenzarchitektur für die Warnsysteme WIND [
Wie in Kapitel 2 dargestellt, zielt unsere Referenzarchitektur auf die nicht-funktionalen Aspekte eines Warnsystems ab. Um unseren Ansatz zu bewerten, definieren wir eine Reihe von nicht-funktionalen Anforderungen die im Anwendungskonetxt Frühwransysteme von besonderer Bedutung sind. Dabei teilen wir die nichtfunktionalen Anforderungen in den folgenden drei Kategorien auf: (1) Funktionsqualitäten, (2) Betriebsqualitäten und (3) Entwicklungsqualitäten. Tabelle 1 gibt einen Überblick über die berücksichtigten Anforderungskriterien:
Tabelle 1: Kategorisierung nicht-funktionaler Anforderungen für Warnsysteme
[
Unter den Betriebqualitäten beschreiben wir die für den Betrieb des Systems relevanten Eigenschaften. Im Kontext von Frühwarnsystemen und deren Krikialität sind wiederum die wichtigsten nicht-funktionalen Anforderungen an die Betriebsqualitäten Leistung, Zuverlässigkeit, Verfügbarkeit, Robustheit und Sicherheit. Unter den Entwicklungs oder Evolutionsqualitäten beschreiben wir die Eigenschaften des Systems für die langfristige Anpassung an sich ändernde Anforderungen. Ausschlaggebend sind die Heterogenität der Anwendungsszenarien, die erwartete Dynamik der Anforderungen und die postulierte Kosteneffizienz. Frühwarnsysteme arbeiten im Allgemeinen in dynamischen Umgebungen, in denen sich Erkennungs-, Vorhersage- und Warntechnologien sowie Reaktionsstrategien im Laufe der Zeit ändern können. Ein wichtiger Aspekt ist, dass Frühwarnsysteme in der Regel für einen langfristigen Betrieb geplant sind, da die mit dem System adressierten Gefahren oft eine permanente Bedrohung darstellen. Daraus folgen die hohehn Anforderungen, die an die langfristige Entwicklungsqualitäten von Frühwarnsystemen gestellt werden. Die relevanten nicht-funktionalen Anforderungen in dieser Kategorie sind Portabilität, Modifizierbarkeit, Interoperabilität und Skalierbarkeit.
In dieser Arbeit konzentrieren wir uns auf die nicht-funktionale Anforderungspaare, die bei der Entwicklung effizienter Warnsysteme für die Praxis entscheidend sind. Diese sind Leistung/Skalierbarkeit, Zuverlässigkeit/Fehlertoleranz, Portabilität/ Modifizierbarkeit und Rückverfolgbarkeit/Testbarkeit.
In diesem Kapitel beschreiben wir eine ereignis- und k-basierte Architektur für
Warnsysteme. Der ereignisgesteuerte Ansatz bedeutet vereinfacht, dass die
Interaktion zwischen Komponenten in dem System ausschließlich oder hauptsächlich
durch interne oder externe Ereignisse ausgelöst wird und die Architektur daruf optmiert
wird. Ein Frühwarnsystem kann allgemein als ein System charakterisiert werden, das
durch externe Ereignisse (z.B. neue Beobachtungen) ausgelöst wird, diese Ereignisse
verarbeitet (z.B. Erkennung einer Gefahr in den Daten) und die resultierenden
Warnungen als Ereignisse für Nutzer bzw. angeschlossene Systeme weiterleitet.
Daher ist es sinnvoll, alle Komponenten auf dem kritischen Pfad eines
Frühwarnsystems basierend auf ereignisgesteuerten Prinzipien zu entwerfen. Soweit
sind wir konform zur bisherigen Referenzarchitektur, wie sie in [
Der Hauptunterschied besteht nun im Schritt vom serviceorientierten, datenbankzentrierten und schichtenbasierten Ansatz hin zu einem rein Mikroservicebasierten Ansatz, der auch im Kontext einer ereignisgesteuerten Architektur sinnvoll ist. Auch wenn Mikroservices als eine konsequente Weiterentwicklung oder eine Variante von Service-orientierten Architekturen (SOA) gesehen werden kann, hat eine Ablösung von SOA entscheidende Auswirkungen auf die Architektur. In einer vereinfachten Beschreibung besteht ein Mikroservice-basiertes System aus einer Anzahl funktionaler kleiner, loser gekoppelter und in sich geschlossener Services, die Implementierungsdetails verbergen und über leichtgewichtige Protokolle über feinspezifizierte Schnittstellen kommunizieren. Die Services sollten normalerweise ihren eigenen Datenspeicher haben und autonom betrieben werden können. Die Hauptaufgabe beim Entwurf von Mikroservice-basierten Architekturen ist die funktionale Dekomposition und das Schnittstellenspezifikation der einzelen Mikroservices. Die Vor- und Nachteile dieses Ansatzes im Kontext von Warnsystemen werden in Kapitel 5 diskutiert. Hier konzentrieren wir uns auf die Beschreibung der Architektur, die in Abbildung 1 dargestellt ist.
Abbildung 1: Architektur für Warnsysteme Die Hauptkomponenten der Architektur sind für die folgenden Funktionen verantwortlich:
Incident Content Management ist für die Verwaltung eingehender Ereignisse verantwortlich. Es nimmt Ereignismeldungen über verschiedene externe Schnittstellen entgegen und speichert diese persistent im Incident Content Storage. Basierend auf einem Abgleich des aktuellen Bedarfs und existierenden Warnungen werden neue oder aktualisierte Ereignisse als Vorfälle an den Alert Notification Generator und damit an den Notification Service weitergeleitet.
Notification Generator ist verantwortlich für das Matching von aktuellen Endnutzerbedarfen, die in Abonenements gespeicherte werden (z.B. aktuelle Position) und Ereignissen. Der Service hat Zugriff auf den Demand-/Alert-Storage, eine spezielle Laufzeitdatenbank, in der die Abonnement- und Ereignisdaten bereits kombiniert wurden. Die Hauptaufgabe des Diesntes besteht dann darin, die Adressen der relevanten Geräte der Endnutzer abzurufen und diese Daten an den Alert Notification Dispatcher zu senden. Darüber hinaus verfügt diese Komponente über einen Speicher, in dem der Benachrichtigungsstatus der einzelnen Geräte gespeichert ist. Der Alert Notification Generator informiert außerdem andere Services darüber, von welchen Geräten erwartet wird, dass sie demnächst Abfragen senden, bevor die Zustellung der Warnung ausgelöst wird. Dies macht es möglich, das System so optimieren, dass die angeforderte Information über einen Cache vorab zur Verfügung gestelt werden können, was die Leistungsfähigkeit bei Abfargen erheblich erhöht.
Dispatcher ist für das Versenden der Benachrichtigungen über verschiedene Kanäle verantwortlich. Er empfängt die vom Alert Notification Generator erzeugten Warnungen zusammen mit den entsprechenden Geräteadressen und sendet die Benachrichtigungen.
bietet eine Schnittstelle, über die Inhalte abgefragt werden können. Dies beinhaltet Abfragen von ausgegebenen Warnunge und relevanten Zusatzinformationen. Die Daten stammen aus dem Alert Content Cache. Der Content-Endpoint ist auf maximale Skalierbarkeit ausgelegt und verwendet dynamische Lastverteilung. Der Alert Content Cache dient als Puffer für den zu liefernden Inhalt (z. B. Zusatztexte und Warnkarten).
Profile-Endpoint und Profile Service: Der Profile-Endpoint stellt die Schnittstelle zur 218 Verfügung, über die der Benutzer Profilinformationen abfragen, hinzufügen oder ändern kann. Ähnlich wie der Content-Endpoint verwendet der Profile-Endpoint eine dynamische Lastverteilung, um unter anderem mehrere Profilaktualisierungen in kurzer Zeit zu ermöglichen. Der Profile-Endpoint ruft Antworten auf Abfragen aus dem Profie-Info-Cache ab, der häufig angeforderte Daten sowie zuletzt geänderte Profilinformationen in einem leistungsstarken Schlüssel/Wert-Cache enthält. Der Device/Location-Manager ist für die Verwaltung aller profilbezogenen Daten im System verantwortlich. Nutzeranfragen werden an den Manager weitergeleitet, wenn sie nicht direkt vom Profile-Info-Cache beantwortet werden können.
Die auf dieser Architektur basierenden Warnsysteme wurden unter Verwendung von serverseitiger JavaScript-Technologie einschließlich über die in dem MEAN-Stack vorgesehenen Technologien wie MongoDB, Express.js, AngularJS, Node.js sowie Redis als Schlüsselwertspeicher implementiert.
Methoden zur Evaluierung von Architekturen stell schon für sich ein eigenes Forschungsgebiet dar. Nach Kenntnisstand gibt es keine formale Bewertungsmethode für nicht-funktionale Anforderungen auf theoretischer Ebene. Tatsächlich hängt die Bewertungsmethode von den zu betrachtenden Kriterien ab und kann oft nur in einer Kombination von empirischen und logischen Schlussfolgerungen bewertet werden. In Abschnitt 3 haben wir relevante nicht-funktionale Kriterien zur Bewertung von Warnsystemen vorgestellt. In dieser Arbeit konzentrieren wir uns bei der Evaluierung auf die relevantesten Kriterienpaare, nämlich Leistung/Skalierbarkeit, Zuverlässigkeit/Fehlertoleranz, Portabilität/Modifizierbarkeit und Rückverfolgbarkeit/ Testbarkeit. Im Folgenden betrachten wir die Eigenschaften der vorgestellent Architektur einzeln nach diesen Kriterien:
Ein öffentliches Warnsystem wie KATWARN mit derzeit über 4 Millionen abonnierten Endnutzern und der Anforderung, innerhalb weniger Minuten mehrere hunderttausend Endnutzer individuell alarmieren zu können, ist offensichtlich ein adäquates empirisches Testfeld für die Leistungsfähigkeit und Skalierbarkeit von Warnsystemen. Eine wesentliche Motivation für ein Redesign der bisherigen SOA-basierten, zentralen 219 datenbankorientierten und schichten-orientierten Architektur von KATWARN waren die Grenzen, die bei mehr als 1 Million Endnutzern erreicht wurden. Aufgrund von effizienten Caching-Mechanismen basierend auf einfachen Schlüssel-Wert-Speichern, der strikten Einhaltung des Prinzips des Seperation of Concerns bei der ServiceAbgrenzung, der optimierten, flexiblen und verteilbaren Ereignisverarbeitung in einen Mikroservice-basierten Ansatz ist die neue Architektur weit überlegen zu der früheren Architektur in Bezug auf die Leistung (teilweise um den Faktor 12). Selbst wenn alle Optimierungspotentiale der früheren Architektur genutzt worden wären, hätte die durch die Architektur gegebenen strukturellen Einschränkungen kein wesentlich besseres Ergebnis erlaubt. Angesichts der aktuellen KATWARN-Produktionsinfrastruktur von 14 Servern (Intel® CoreTM i7-6700 Quad-Core Skylake 32 GB DDR4 RAM, 2 x 250 GB SATA 6 GB / s SSD (RAID 1), 1 GBit / s-Port) kann leicht berechnet werden, was ein beispielweise ein Leistungssteigerungsfaktor von12 in Bezug auf Hardware und Wartungskosten bedeutet. Draüberhinaus bietet die neue Architektur viel gezieltere und effizientere Möglichkeiten der Skalierbarkeit. Während die alte, monolithische und auf zentrale Datenbanken orientierte Architektur nur die Möglichkeit bot, über logische Lastverteilung und neue Instanzen des gesamten Warnsystem zu skalieren, kann man sich bei der neuen Architektur die spezifische Skalierung einzelner Services konzentrieren und diese sogar dynamisch durchführen, indem zusätzliche Services zur Laufzeit gestartet werden. Beispielsweise besteht die höchste Verarbeitungslast bei den Services Sender und der Content-Endpoint. Daher werden diese Services derzeit als 8 identische Instanzen auf einzelnen Hochleistungsservern betrieben, um ausreichend Leistungsspielraum für bis zu 10 Millionen Endnutzer bereitzustellen.
In diesem Bereich müssen wir zwischen zwei Aspekten unterscheiden: erstens die Fähigkeit, Fehler zu vermeiden, und zweitens die Robustheit des Systems, wenn Fehler auftreten. Bei der Entwicklung kritischer Systeme muss oft ein Kompromiss zwischen beiden Aspekten gefunden werden. Ein Hauptkritikpunkt bei der Verwendung von Mikroservices im Kontext kritischer Systeme ist die lose Kopplung zwischen Services durch hauptsächlich asynchrone Kommunikation, die auch als "Fire and Forget"-Paradigma bezeichnet wird. Eines der wichtigsten Mikroservics-Prinzipien besteht darin, dass der Ausfall eines Services die Reaktion auf oder Auslösung von 220 Ereignissen in anderen Sevices nicht blockieren sollte. Wenn ein Service fehlschlägt, kann er leicht (sogar automatisch) neu gestartet werden. Asynchrone Ereignisse von oder zu diesem Service können jedoch in dieser Zeit verloren gehen. Offensichtlich ist ein solches Verhalten hinsichtlich der Robustheit vorteilhaft, erzeugt jedoch einen möglichen Anteil von Funktionsfehlern. (in unserem Fall Warnmeldung, die nicht an die Endbenutzer geliefert wird). Es können jedoch Maßnahmen gegen solche Funktionsfehler in einem Mikroservice-basierten System ergriffen werden, entweder durch Einführung von Zuständen in den Services (was gegen das allgemeine Prinzip von Mikroservices verstoßen würde, die im Allgemeinen zustandslos solletn) oder durch Verwendung von Transaction-Caches zwischen kritischen Services. Der große Vorteil unserer neuen Architektur ist hier die erhöhte Robustheit, insbesondere im Kontext einer Massenanwendungen. Während die alte Architektur eine teure, vollständige Systemredundanz erforderte, z. B. falls eine Software- oder Hardwarekomponente ausfällt, weist die neue Architektur selbst dann eine hohe Robustheit auf, wenn ein kompletter Server ausgefallen ist, da identische Services auf anderen Servern sofort für den fehlgeschlagenen Service einspringen können. Unsere Messungen zeigen, dass dabei die Kosten von Funktionsfehlern relativ gering sind (unter 0,00003% der möglicherweise nicht ausgelieferten Einzelwarnungen).
Wie in vielen anderen Bereichen beobachten wir im Katastrophenmanagement einen
generellen Wandel von isolierten monolithischen Implementierungen hin zu vernetzten
Aufgaben und Prozessen in einem “Systems of Systems”-Ansatz. Dies erhöht nicht
nur die Anforderungen an die Interoperabilität, sondern auch die funktionale
Anpassungsfähigkeit von Systemen. Darüber hinaus sollten die Systeme für
verschiedene Aufgaben, die sich im Katastrophenmanagement entwickeln, immer
flexibler und erweiterbarer werden. In [
Abbildung 3: Vereinfachte Architektur des deutschen KATWARN-Systems Abbildung 4: Architektur des Warnsystem für Deutschland und Österreich
222 In Abbildung 3 sehen wir eine vereinfachte Ansicht der Architektur es bisherigen Warnsystems für Deutschland. In Abbildung 4 sehen wir die implementierte Lösung für Österreich und Deutschland. Es werden nicht vorhergesehene Anforderungen erfüllt, indem lediglich relevante Dienste für die Roamingfunktionalität miteinander verbunden werden, ohne Schnittstellen zu ändern, Services hinzuzufügen oder den Code zu ändern.
Selbst wenn dieser Fall eher ein ideale Ausnahme darstellt, unterstreicht er doch stark die grundsätzlichen Qualitäten dieser Architektur in Bezug auf Portabilität und Modifizierbarkeit. In einem weiteren Schritt zielen wir auf eine Lösung ab, bei der österreichische und deutsche Services als Backup für Ausfälle in den Infrastrukturen eines Systems dienen können, wiederum allein durch Änderung der Topologie der Architektur.
Einer der Hauptnachteile des neuen Architekturparadigmas ist die kompliziertere Rückverfolgbarkeit und Testbarkeit. Während das Verhalten eines einzelnen Services noch leicht verfolgt und getestet werden kann, ist das Verhalten der gesamten ServiceChoreographie in dem integrierten System aufgrund der größeren Anzahl, der losen Kopplung und des asynchronen Verhaltens der Service viel komplexer als beispeilsweise in SOA. Das mögliche Hinzufügen gemeinsamer Transaktions-IDs für alle Dienste ist schwierig zu implementieren, würde die Kommunikation unnötig erhöhen und den Grundsatz der Unabhängigkeit der Dienste verletzen. Dies führt zu einem allgemeinen Problem der Verwaltung großer komplexer Mikroservice-basierter Architekturen. Aufgrund des relativ neuen Ansatzes sind für diese Probleme nach unserer Kenntnis noch keine geeigneten Managament-Werkzeuge entwickelt worden.
In dieser Arbeit haben wir eine neue Referenzarchitektur für Warnsysteme basierend auf ereignisgesteuerten und Mikroservice-orientierten Paradigmen vorgestellt. Die Machbarkeit und die Vorteile des Ansatzes wurden anhand zentraler nicht-funktionaler Anforderungen aufgezeigt, die durch die aktuellen Implementierungen der KATWARNWarnsysteme parktisch getestet wurden. Der Ansatz hat seine Hauptvorteile in Bezug auf Leistung/Skalierbarkeit, Zuverlässigkeit/Fehlertoleranz und Portabilität/Modifizierbarkeit gegenüber klassischen SOA-Architekturen. Wir haben jedoch auch Schwachstellen in Bezug auf Rückverfolgbarkeit/Testbarkeit entdeckt, die mit einem allgemeinen Problem der Planung, Verwaltung und Steuerung großer und komplexer
7