ISR-Daten treffen an einem Gefechtsstand gleichzeitig aus einem Dutzend Richtungen ein. UAV-Telemetrie strömt über eine dedizierte Funkverbindung. Elektronische Kampfführungssensoren übermitteln Abfangereignisse über einen verschlüsselten TCP-Feed. Artilleriebeobachter melden Gitterreferenzen per Sprech- oder Digitalfunk. SIGINT-Plattformen produzieren angereicherte Entitätsberichte in unregelmäßigen Abständen. Jede dieser Quellen hat ihr eigenes Format, ihre eigene Aktualisierungsrate und ihr eigenes Zuverlässigkeitsprofil. Die Herausforderung besteht nicht im Datenerwerb — sondern darin, die Daten rechtzeitig zu verstehen, damit die Informationen Entscheidungen beeinflussen können.

Corvus.Head ist das operative Lageinformations-Dashboard von Corvus Intelligence, das genau diese Art von Multi-Source-Gefechtsfelddaten in einer einzigen, strukturierten Oberfläche für militärische Führung, Nachrichtendienstteams und Einsatzplaner zusammenführt. Dieser Artikel ist ein technischer Bericht über die Systemarchitektur: die Ingestion-Pipeline, die heterogene Feeds normalisiert, die PowerBI-Integration für analytische Visualisierungen, die geospatiale Engine für Heatmaps und Hotspots, die Trendprognose-Schicht und die Azure-Hosting-Topologie, die die Latenz innerhalb operativer Toleranzgrenzen hält.

Daten-Ingestion-Schicht: heterogene Sensorfeeds normalisieren

Die erste Architekturentscheidung in jedem Multi-Source-ISR-System ist, wie die Vielfalt der vorgelagerten Datenformate aufgenommen werden soll, ohne dass sich diese Vielfalt in die Verarbeitungs- und Visualisierungsschichten fortpflanzt. Corvus.Head verwendet ein Quelladapter-Muster: Jeder Sensor- oder Feed-Typ erhält einen dedizierten Adapter-Dienst, dessen einzige Aufgabe es ist, sich mit der Quelle zu verbinden, deren natives Format zu parsen und normalisierte kanonische Ereignisse auf einen internen Message Bus auszugeben.

Das kanonische Ereignisschema ist bewusst minimal gehalten. Jedes Ereignis enthält: einen eindeutigen Entitätsidentifikator, ein Quellentyp-Tag, Breiten- und Längengrad in WGS-84-Dezimalgrad, Höhe in Metern über dem mittleren Meeresspiegel (null, wenn die Quelle keine Höhe liefert), Kurs und Geschwindigkeit soweit verfügbar, eine Klassifizierungsbezeichnung (freundlich, feindlich, unbekannt, neutral, ausstehend), einen UTC-Zeitstempel am Ereignisursprung und ein freiformatiges Metadatenobjekt für quellenspezifische Felder, die nicht dem Kernschema entsprechen. Felder, die eine Quelle nicht liefern kann, werden auf null gesetzt statt geschätzt — das Erfinden von Daten in der Normalisierungsschicht ist gefährlicher als der Umgang mit Null-Werten nachgelagert.

Adapter verbinden sich mit ihren Quellen über TCP-Sockets, MQTT-Subscriptions, REST-Polling-Schleifen oder File-Drop-Beobachter, je nachdem, was die jeweilige Quelle unterstützt. Verbindungsfehler werden im Adapter mit exponentiellem Backoff behandelt; ein fehlgeschlagener Adapter blockiert niemals andere Adapter oder den Message Bus. Jeder Adapter veröffentlicht auf seinem eigenen benannten Topic auf dem Bus, damit nachgelagerte Verbraucher selektiv nach Quellentyp abonnieren können. Die Bus-Technologie ist Apache Kafka auf Azure Event Hubs: Kafkas Consumer-Group-Semantik erlaubt es der Fusionsmaschine, der Analyse-Pipeline und der geospatialen Engine, denselben Stream jeweils unabhängig zu konsumieren, ohne Koordination zu erfordern.

Schlüsselerkenntnis: Die Normalisierung muss an der Adaptergrenze stattfinden — nicht in der Fusionsmaschine, nicht in der Visualisierungsschicht. Jede nachgelagerte Schicht setzt voraus, dass sie saubere, typisierte, schemavalide Ereignisse empfängt. Verstöße gegen diesen Vertrag verursachen eine stille Datendegradation, die in der Produktion extrem schwer zu diagnostizieren ist.

PowerBI-Integration: warum es für Verteidigungs-Dashboards gewählt wurde

Die analytische Visualisierungsschicht von Corvus.Head — Diagramme, Trendlinien, Periodenvergleiche und Domänenaufschlüsselungen — basiert auf Microsoft PowerBI Embedded unter Azure. Die Entscheidung für PowerBI statt eines eigenen Diagramm-Stacks ist bewusst und erklärenswert, da sie für Ingenieure, die PowerBI eher mit Business Intelligence als mit Verteidigungsanwendungen verbinden, kontraintuitiv erscheint.

Das praktische Argument lässt sich auf drei Fähigkeiten reduzieren. Erstens bietet die DAX-Engine von PowerBI eine ausgereifte, gut getestete Berechnungsschicht für ermittelte Metriken: Ereignisraten pro Rasterzelle pro Stunde, Quellenvertrauenswürdigkeitswerte, prozentuale Periodenveränderungen und gleitende Durchschnitte. Die DAX-Berechnungssemantik in einem eigenen JavaScript-Diagramm-Stack nachzubauen ist ein jahrelanger Entwicklungsaufwand, der Ressourcen von der Sensorintegrationsarbeit abzieht, die die Plattform tatsächlich differenziert.

Zweitens unterstützt PowerBI Embedded den DirectQuery-Modus gegen Azure Synapse Analytics, was bedeutet, dass das Dashboard voraggregierte Analysetabellen abfragen kann, ohne Rohereignisdaten in den Browser zu laden. Dies hält die Abfragezeiten für 90-Tage-Analysefenster mit Millionen von Ereignissen unter 1,5 Sekunden — eine Leistung, die mit einem Eigenentwicklungsansatz erhebliche Infrastrukturinvestitionen erfordern würde.

Drittens sind die Datenmodell-Versionierung und der Berichtsaktualisierungspfad von PowerBI Verteidigungsprogrammmanagern vertraut, die Analyseberichte über mehrjährige Verträge hinweg pflegen müssen. Die PowerBI-Berichtsdefinition (.pbix) wird zu einem versionierten Artefakt, das ohne erneutes Deployment der zugrunde liegenden Plattformsoftware aktualisiert, überprüft und genehmigt werden kann.

Die Integrationsarchitektur verwendet das PowerBI Embedded JavaScript SDK, um Berichte in iFrames innerhalb der Corvus.Head-Shell zu rendern. Sicherheitsfilter auf Zeilenebene werden beim Einbetten anhand der Zugriffsattribute des Benutzers aus dem Sitzungstoken angewendet, sodass PowerBI-Berichte nur Daten anzeigen, die der anfragende Benutzer einzusehen berechtigt ist — obwohl der PowerBI-Datensatz selbst den vollständigen Korpus enthält.

Schlüsselerkenntnis: Der PowerBI-DirectQuery-Modus beseitigt die Notwendigkeit einer separaten Reporting-Datenbank oder einer Vorberechnungs-Pipeline für die meisten analytischen Abfragen. Der Kompromiss besteht darin, dass DirectQuery-Berichte nicht auf Browser-Ebene gecacht werden können — jede Filterinteraktion löst eine Live-Synapse-Abfrage aus. Planen Sie Ihre Synapse-Tabellenpartitionierungsstrategie vor dem ersten Bericht, nicht danach.

Geospatiale Engine: Heatmaps, Hotspots und Ereignisdichte

Die geospatiale Anzeigeschicht dient einem anderen Zweck als die analytischen Diagramme. Während PowerBI aggregierte Muster über die Zeit zeigt, zeigt die Kartenschicht, wo gerade Dinge geschehen und wo sich Aktivität in der letzten Beobachtungsperiode konzentriert hat. Corvus.Head rendert drei Arten von geospatialen Overlays auf einer Basiskartenebene: Entitätspositionsspuren (über WebSocket-Push aktualisiert), Ereignisdichte-Heatmaps und diskrete Hotspot-Markierungen.

Ereignisdichte-Heatmaps werden serverseitig mit einem räumlichen Hash-Raster mit konfigurierbarer Zellgröße (Standard: 500 Meter) berechnet. Jedes Ereignis, das durch die Ingestion-Pipeline eingeht, erhöht den Dichtewert der Zelle, die seinen Standort enthält, gewichtet durch eine Aktualitätsabklingfunktion — Ereignisse, die älter als sechs Stunden sind, tragen exponentiell weniger zum Zellenwert bei. Die Abklingfunktion verhindert, dass historische Aktivität die Heatmap dauerhaft verzerrt, und stellt sicher, dass die Visualisierung das aktuelle Lagebild widerspiegelt und nicht das kumulative historische.

Das Heatmap-Raster wird nach einem konfigurierbaren Zeitplan (Standard alle 60 Sekunden) neu berechnet und als GeoJSON FeatureCollection von Zellenpolygonen mit Dichteattributen an die Clients gesendet. Der Browser rendert dies mit einer WebGL-Kartenschicht mit einer fünfstufigen Farbrampe von Dunkelblau (geringe Dichte) über Bernstein bis Rot (hohe Dichte). Operatoren können Domänenfilter anwenden — nur EW-Ereignisse oder nur UAV-Beobachtungen anzeigen — was eine serverseitige Raster-Neuberechnung gefiltert nach den ausgewählten Quellentypen auslöst. Dadurch wird ein vollständiges Browser-seitiges Neu-Rendering der zugrunde liegenden Kartengeometrie vermieden.

Hotspot-Markierungen sind diskrete Punkte, die automatisch generiert werden, wenn eine Cluster von Ereignissen in einer einzelnen Rasterzelle einen konfigurierbaren Schwellenwert innerhalb eines gleitenden Zeitfensters überschreitet. Der Hotspot-Detektor läuft als separater Mikrodienst, der den kanonischen Ereignis-Bus abonniert und einen DBSCAN-Varianten-Clustering-Algorithmus über ein rollendes 30-Minuten-Ereignisfenster auswertet. Wenn ein Cluster den Schwellenwert überschreitet, wird ein Hotspot-Datensatz in die Datenbank geschrieben und über den WebSocket-Push-Kanal an verbundene Dashboard-Clients gesendet. Hotspots laufen automatisch ab, wenn die Cluster-Aktivität für einen anhaltenden Zeitraum unter den Schwellenwert fällt.

Trendprognose: tägliche, wöchentliche und monatliche Zeiträume

Trendprognosen geben Kommandeuren eine quantitative Grundlage, um das operative Tempo vorauszusehen, statt darauf zu reagieren. Corvus.Head stellt Prognosen für Ereignisaktivität über drei Zeiträume bereit — täglich, wöchentlich und monatlich — berechnet mit einem saisonalen Zerlegungsmodell, das auf zellenspezifische Zeitreihendaten angewendet wird.

Die Prognose-Pipeline läuft auf Azure Databricks nach einem geplanten Zeitplan (stündlich für Tagesprognosen, nächtlich für wöchentliche und monatliche Prognosen). Sie ruft die letzten 90 Tage Ereigniszählungen aggregiert pro Rasterzelle und Zeitbucket aus Azure Synapse ab, wendet STL-Zerlegung (Seasonal-Trend decomposition using LOESS) an, um saisonale und Trendkomponenten zu extrahieren, und erstellt Vorwärtsprojektionen mit Konfidenzintervallen, die aus der Restvarianz abgeleitet werden. Die Ergebnisse werden als vorberechnete Prognose-Spalten zurück in Synapse geschrieben, die PowerBI über DirectQuery abfragen kann, ohne die Zerlegung live auszuführen.

Die Entscheidung für Vorberechnung statt Bedarfsberechnung ist bewusst. STL-Zerlegung auf 90 Tage Daten über Tausende von Rasterzellen ist rechenintensiv — eine bedarfsgerechte Ausführung als Reaktion auf eine Dashboard-Abfrage würde inakzeptable Latenzen erzeugen. Die Vorberechnung verlagert den Aufwand auf einen geplanten Batch-Job und hält die Dashboard-Abfragezeiten für jede vom Benutzer ausgeführte Prognoseabfrage unter 1,5 Sekunden.

Filterarchitektur: Domänen- und Zeitraum-Drill-down

Ein Dashboard, das alles anzeigt, ist operativ genauso nutzlos wie eines, das nichts anzeigt. Die Filterarchitektur bestimmt, ob Kommandeure das für ihre aktuelle Entscheidung relevante Signal schnell aus dem Rauschen eines vollständigen Multi-Source-Lagebilds isolieren können.

Corvus.Head implementiert Filterung entlang zweier Achsen: Domäne (Quellentyp oder Entitätsklassifizierung) und Zeitraum (letzte Stunde, letzte 6 Stunden, letzte 24 Stunden, letzte 7 Tage oder benutzerdefinierter Bereich). Filter werden auf drei Ebenen angewendet: die API-Abfrageschicht (die nur passende Ereignisse aus Synapse abruft), die Message-Bus-Abonnementschicht (die nur relevante Quellentyp-Topics für den Live-WebSocket-Feed abonniert) und die PowerBI-Berichtsschicht (die DAX-Filterkontext auf alle Measures anwendet). Dieser dreischichtige Ansatz stellt sicher, dass Filteränderungen konsistent über alle visuellen Komponenten hinweg widergespiegelt werden, ohne dass eine browser-seitige Nachverarbeitung eines vollständigen Datensatzes erforderlich ist.

Der Filterzustand wird in der Dashboard-Shell als URL-serialisierbares Zustandsobjekt gepflegt, wodurch Kommandeure bestimmte gefilterte Ansichten mit ihrem Stab als Lesezeichen setzen und teilen können. Ein Brigadegeheimdienstoffizier kann eine bestimmte gefilterte Ansicht — EW-Ereignisse, letzte 6 Stunden, nördlicher Sektor — als URL an Untergebene senden, und die Empfänger sehen eine identische gefilterte Ansicht, wenn sie den Link öffnen.

Schlüsselerkenntnis: Wenden Sie Filter in der Datenabrufschicht an, nicht in der Anzeigeschicht. Das Abrufen aller Ereignisse und das Filtern in JavaScript liefert falsche Ergebnisse, wenn das Datenvolumen das Browser-Speicherlimit überschreitet, und es macht Daten für Benutzer zugänglich, die nicht berechtigt sind, sie einzusehen, auch wenn die Benutzeroberfläche sie nicht anzeigt.

Azure-Hosting-Topologie und Latenzkonsiderationen

Corvus.Head wird auf Azure Government Cloud (Azure for Government in den USA, entsprechende souveräne Cloud-Regionen für Partnernationen) gehostet. Die Hosting-Topologie ist um drei Latenzbudgets ausgelegt: nahezu Echtzeit für Entitätspositionsaktualisierungen (Ziel: unter 3 Sekunden End-to-End), analytische Abfrageantwort (Ziel: unter 1,5 Sekunden für voraggregierte Abfragen) und Kartenkachellieferung (Ziel: unter 500 ms für gecachte Kacheln).

Die Ingestion-Adapter und der Message Bus (Azure Event Hubs im Kafka-kompatiblen Modus) laufen in derselben Azure-Region wie die klassifizierten Datenquellen, was den Netzwerkhop zwischen Sensorsystemen und der Normalisierungsschicht minimiert. Die Fusionsmaschine und das WebSocket-Gateway werden als Azure Kubernetes Service-Workloads in derselben Region bereitgestellt. Die PowerBI Embedded-Kapazität und der Azure Synapse Analytics-Arbeitsbereich sind in derselben Region bereitgestellt, um regionsübergreifende Datenübertragungslatenzen bei DirectQuery-Aufrufen zu vermeiden.

Die Kartenkachellieferung verwendet Azure Blob Storage mit Azure CDN-Beschleunigung für nicht klassifizierte Basisschicht-Kacheln. Klassifizierte Overlay-Kacheln — Geheimdienstannotationsschichten, Freund-Kräfte-Dispositions-Overlays — werden von einem dedizierten Kachelserver innerhalb des sicheren Perimeters bereitgestellt, der kein CDN verwendet. Kachelserver-Antwortzeitziele werden durch einen Gesundheitsmonitor durchgesetzt, der das Betriebsteam benachrichtigt, wenn die p95-Kachellieferung 800 ms überschreitet.

Für vorwärts eingesetzte Konfigurationen, bei denen Azure-Konnektivität nicht verfügbar oder unzuverlässig ist, unterstützt Corvus.Head einen containerisierten Einzelserver-Deployment-Modus mit Docker Compose. In diesem Modus läuft der vollständige Stack — Ingestion-Adapter, Fusionsmaschine, Kachelserver, ein lokaler Kafka-Broker und eine PostgreSQL-Datenbank als Synapse-Ersatz — auf einem gehärteten Server im taktischen Netzwerk. PowerBI wird durch eine leichtgewichtige Analyse-Engine mit vorgefertigten Vega-Lite-Diagrammspezifikationen ersetzt, die von einer lokalen REST API gespeist werden. Das Latenzprofil ändert sich in diesem Modus erheblich: Ohne die verwalteten Azure-Dienste ist das Ops-Team für die Überwachung und Skalierung der lokalen Infrastruktur verantwortlich, und einige Analysefunktionen mit 90-Tage-Historientiefe werden auf einen lokalen 30-Tage-Cache reduziert.

Schritt für Schritt: eine neue Datenquelle in Corvus.Head integrieren

Die Adapterarchitektur macht das Einbinden neuer Sensortypen zu einem wiederholbaren Entwicklungsprozess statt jedes Mal zu einem einmaligen Integrationsprojekt. Die folgenden Schritte beschreiben den standardmäßigen Integrationspfad.

Schritt 1 — Quellschema und Aktualisierungsrate definieren. Dokumentieren Sie das Datenformat (CoT XML, JSON, Binärprotokoll), die erwartete Aktualisierungsrate in Nachrichten pro Sekunde und die maßgeblichen Feldnamen für Position, Zeit, Entitätstyp und Klassifizierung. Diese Schemadefinition wird zum Vertrag für den Adapter.

Schritt 2 — Den Ingestion-Adapter implementieren. Schreiben Sie einen quellenspezifischen Adapter, der sich mit dem Feed verbindet und normalisierte kanonische Ereignisse auf den Message Bus ausgibt. Der Adapter behandelt Verbindungswiederholungen, Teilnachrichtenneuzusammenstellung und quellenspezifische Authentifizierung. Er darf den Bus bei einem Verbindungsfehler niemals blockieren.

Schritt 3 — Felder auf das kanonische Ereignisschema abbilden. Transformieren Sie jede eingehende Nachricht in das kanonische Corvus.Head-Ereignisformat. Felder, die nicht zugeordnet werden können, werden am Adapter verworfen. Felder, die der Sensor nicht liefern kann, werden auf null gesetzt statt erfunden.

Schritt 4 — Assoziationsregeln der Fusionsmaschine konfigurieren. Fügen Sie den neuen Quellentyp zur Assoziationsregeltabelle der Fusionsmaschine hinzu. Geben Sie den räumlichen Näherungsschwellenwert und das Zeitfenster an, die verwendet werden, um Meldungen dieser Quelle mit vorhandenen Spuren zu assoziieren, und legen Sie das Quellengenauigkeitsgewicht für den Positionsschätzer fest.

Schritt 5 — Die Quelle im PowerBI-Datenmodell registrieren. Fügen Sie den neuen Quellentyp als Dimensionswert in der SourceType-Tabelle hinzu. Überprüfen Sie, ob bestehende Slicer und DAX-Measures den neuen Wert verarbeiten, ohne bestehende Berichte zu beschädigen.

Schritt 6 — Latenz und Durchsatz in der Staging-Umgebung validieren. Führen Sie den Adapter gegen eine Wiedergabe historischer Quelldaten mit der doppelten Echtzeit-Rate aus. Messen Sie die End-to-End-Latenz vom Nachrichtenempfang bis zur Dashboard-Anzeige. Bestätigen Sie, dass die p99-Latenz unter 3 Sekunden bleibt und die Warteschlangentiefe des Message Bus unter anhaltender Last nicht unbegrenzt wächst.

Schritt 7 — In Produktion aktivieren und überwachen. Stellen Sie den Adapter mit Feature-Flag-Kontrolle bereit, damit er ohne ein Rollback deaktiviert werden kann, falls Probleme auftreten. Überwachen Sie die Dead-Letter-Queue, die quellenspezifische Ereignisrate und die Track-to-Report-Assoziationsrate der Fusionsmaschine. Ein Abfall der Assoziationsrate unter 80 % weist typischerweise auf eine Schemaabweichung hin, die durch ein Firmware-Update der Quelle eingeführt wurde.

Häufig gestellte Fragen

+Warum verwendet Corvus.Head PowerBI statt einer eigenen Diagrammbibliothek?

PowerBI auf Azure bietet Enterprise-Datenmodellierung, DAX-basierte berechnete Measures und einen ausgereiften DirectQuery-Pfad, der Echtzeit-nahe Visualisierungen ermöglicht, ohne Daten in einer separaten Reporting-Datenbank vorzuaggregieren. Den entsprechenden Funktionsumfang mit einer eigenen Diagrammbibliothek nachzubauen, würde erfordern, die DAX-Engine, das Datenmodell-Versionierungssystem und die Export-/Einbettungsinfrastruktur zu replizieren — ein jahrelanger Entwicklungsaufwand, der Ressourcen von der missionskritischen Sensorintegrationsarbeit abzieht.

+Wie verarbeitet Corvus.Head Daten aus Quellen mit unterschiedlichen Aktualisierungsraten?

Jeder Quellentyp hat eine registrierte Aktualisierungshäufigkeit in der Ingestion-Schicht. Langsame Quellen (SIGINT, Logistik) werden auf ein separates Topic mit einem längeren Aufbewahrungsfenster übertragen. Schnelle Quellen (UAV-Telemetrie, Radar) werden über den Hochprioritätspfad des Message Bus verarbeitet. Die Fusionsmaschine pflegt einen Veraltungszeitstempel pro Quelle und Spur und markiert Spuren als beeinträchtigt, wenn eine Quelle nicht innerhalb des zweifachen ihrer erwarteten Häufigkeit gemeldet hat.

+Wie hoch ist die End-to-End-Latenz, bis ein Sensorereignis im Dashboard erscheint?

Unter normalen Netzwerkbedingungen beim Azure-gehosteten Deployment beträgt die typische End-to-End-Latenz vom Empfang der Sensornachricht bis zur Pixel-Aktualisierung im Dashboard unter 2 Sekunden. Die Aufschlüsselung lautet: Adapter-Normalisierung (50–150 ms), Message-Bus-Transit (unter 50 ms), Fusionsmaschinen-Verarbeitung (100–300 ms), PowerBI-DirectQuery-Aktualisierung (500–1200 ms) und Browser-Rendering (unter 100 ms). Die geospatiale Kartenschicht aktualisiert sich schneller — Spurpositionsänderungen über den WebSocket-Push-Kanal erscheinen innerhalb von 300–500 ms unabhängig vom PowerBI-Aktualisierungszyklus.

+Wie werden Heatmaps aus Multi-Source-Ereignisdaten erzeugt?

Die geospatiale Engine aggregiert Ereignisse in einem konfigurierbaren Raster (Standard: 500-m-Zellen) mithilfe eines räumlichen Hash. Jede Zelle akkumuliert einen gewichteten Ereignisdichtewert: Ereignisse gewichtet nach Aktualität (exponentielle Abnahme mit einer Halbwertszeit von 6 Stunden) und Quellenvertrauenswürdigkeit. Das Dichteraster wird als WebGL-Heatmap-Schicht mit einer konfigurierbaren Farbrampe gerendert. Domänenfilter (nur EW oder nur UAV) berechnen das Raster serverseitig neu und senden eine aktualisierte Kachel an den Client — ein vollständiges Neu-Rendering der zugrunde liegenden Karte wird so vermieden.

+Wie funktioniert die Trendprognose-Engine über tägliche, wöchentliche und monatliche Zeiträume?

Die Prognose-Engine wendet ein saisonales Zerlegungsmodell (STL — Seasonal-Trend decomposition using LOESS) auf Ereignisanzahl-Zeitreihen an, die pro Rasterzelle aggregiert werden. Tägliche, wöchentliche und monatliche Saisonalitätskomponenten werden von einem Azure Databricks-Batch-Job extrahiert. Prognose-Konfidenzintervalle werden aus der Restvarianz berechnet. Die Ergebnisse werden als vorberechnete Spalten in Azure Synapse gespeichert, sodass das PowerBI-Modell sie über DirectQuery abfragen kann, ohne die Zerlegung live auszuführen — wodurch die Antwortzeiten selbst bei 90-Tage-Prognosehorizonten unter 1,5 Sekunden gehalten werden.