ESW Dev

Einordnung

Die Einsatzsoftware muss auf den zuvor definierten Endgeräten (Smartphone, Fahrzeug- oder Stab-Arbeitsplatz, Wandmonitor) funktionieren (siehe Zielplattformen). Dabei ist die Offline-Fähigkeit gemäß Netzausfall-Abschnitt grundlegend. Die Architektur muss daher robuste Arbeitsweisen unterstützen, die den Anforderungen des mentalen Modells der Helfer entsprechen.

Verschiedene technische Ansätze sind denkbar, um Clients zu realisieren. Im Folgenden werden typische Optionen skizziert und anhand ihrer Offline-, Sicherheits- und Wartungs-Eigenschaften bewertet.

Browser-basierte Webanwendungen

Beschreibung: Die Anwendung läuft in einem Webbrowser. Auf PC und Laptop erfolgt der Zugriff über Edge oder Firefox, auf dem Smartphone über einen Mobilbrowser oder eventuell eine eingepackte Web-View. Ein wesentlicher Vorteil ist die Plattformunabhängigkeit: PWAs (Progressive Web Apps) etwa laufen auf nahezu jedem Gerät mit aktuellem Browser. Updates sind zentral möglich, Nutzer müssen nichts manuell installieren.

Vorteile: Einheitliche Codebasis, einfache Pflege, geringe Anschaffungskosten. Plattformunabhängigkeit erlaubt schnelle Verteilung auf unterschiedlichsten Geräten. Auch Browsertechnologien bieten mittels Caching eine gewisse Offline-Funktion (ServiceWorker, IndexedDB).

Nachteile: Native Hardwarezugriffe (GPS, Kamera, Sensoren) sind oft eingeschränkt. Bei länger anhaltendem Komplettausfall der Infrastruktur verlieren Webanwendungen schnell ihre Funktion, da keine dauerhafte Datenhaltung auf Servern möglich ist. Im Extremfall fehlt die verlässliche Synchronisation ganz. Zudem sind Standard-Web-Apps browserabhängig (z. B. Edge vs. Chrome) und können zusätzliche Sicherheitsrisiken durch die Sandbox-Ebene haben. Große Datenmengen oder komplexe Berechnungen (Charting, GIS) würden im Browser-Rendering an Performance-Grenzen stoßen.

Progressive Web App (PWA)

Beschreibung: Eine PWA ist eine Web-App mit erweiterten Offline-Fähigkeiten. Mittels ServiceWorker und Caching können Webinhalte vorab auf dem Gerät gespeichert werden. Der Nutzer kann die PWA auf seinem Home-Bildschirm installieren, ähnlich wie eine native App.

Vorteile: PWAs kombinieren viele Web-Vorteile mit eingeschränkter Offline-Funktion. Sie bleiben plattformunabhängig und erfordern nur eine Entwicklung für alle Clients. Durch Caching stellen sie Basisfunktionen auch bei vorübergehenden Netzunterbrechungen bereit. Updates werden weiterhin serverseitig ausgeliefert, Wartung und Rollout sind zentral steuerbar. Die Entwicklungs- und Betriebskosten sind gegenüber voll-nativen Lösungen geringer.

Nachteile: PWAs bieten nur teilweise Offline-Arbeitsfähigkeit. Bei kompletten Infrastruktur-Ausfällen (z. B. Funkloch über Tage) sind sie nicht vollumfänglich autark. Die Synchronisation von Daten kann erst bei wieder verfügbarer Verbindung erfolgen. Unter Dauerbelastung des Netzes stoßen PWAs an technische Grenzen. Auch der Zugriff auf Gerätedaten ist gegenüber nativen Apps eingeschränkt. Für aufwändige oder zeitkritische Anwendungen (z. B. Echtzeit-GIS, Simulation) ist die browserbasierte Laufzeit ungeeignet. Schließlich kann die Web-Architektur zu erhöhten Sicherheitsanforderungen führen, da die Kontrolle über Datenflüsse und Speicherorte weniger direkt ist.

Native Apps (Android und iOS)

Beschreibung: Vollständig native Anwendungen, entwickelt jeweils für Android und iOS. Sie werden direkt auf dem Gerät installiert und laufen als eigenständige Programme.

Vorteile: Native Apps bieten umfassenden Zugriff auf alle Geräteschnittstellen (GPS, Kamera, Sensoren) und sind vollständig offlinefähig. Sie können lokale Datenbanken (z. B. SQLite) nutzen und komplexe Funktionen performant ausführen. Betriebssystemseitige Sicherheitsfunktionen (App-Sandbox, Verschlüsselung) sind integriert. Die Benutzerführung kann genau dem mentalen Modell entsprechen.

Nachteile: Zwei oder mehr Codebasen (Android/iOS) erhöhen Entwicklungs- und Wartungsaufwand. Für jede Plattform müssen eigene Builds und Updates bereitgestellt werden. In Behörden-IT kann die Verteilung (App-Stores oder Enterprise-Deployment) aufwändiger sein. Es besteht Abhängigkeit von Mobilfunk- und OS-Updates. Nutzerdaten müssen über eigene Mechanismen synchronisiert werden.

Hybride und Cross-Platform-Frameworks

Beschreibung: Lösungen wie React Native, Flutter, Xamarin oder Cordova erlauben die Entwicklung einer einzigen Codebasis für Android und iOS (teilweise Desktop). Die Anwendung kann eine Mischung aus Web-View und nativen Modulen sein.

Vorteile: Code-Wiederverwendung über Plattformen hinweg, geringerer Entwicklungsaufwand als bei komplett separaten Apps. Offline-Fähigkeit kann ähnlich wie bei nativen Apps realisiert werden. Moderne Frameworks sind leistungsstark und bieten Bibliotheken für gängige Anforderungen (Karten, Datenbank, Sensoren).

Nachteile: Hybride Apps sind oft komplexer als reine Web- oder native Apps. Sie können Performance-Einbußen haben und erfordern gründliche Tests. Die Abhängigkeit von Framework-Updates ist zu beachten. Dennoch profitieren sie von den meisten Vorteilen nativer Apps (Offline, Hardwarezugriff) bei reduzierter Doppelarbeit.

Lokale Desktop-/Vollclient-Anwendungen

Beschreibung: Für Windows-Arbeitsplätze oder Raspberry-Pi-basierte Monitore können auch native Desktop-Programme oder lokal installierte Web-Server (Single-Page-Apps in Kiosk-Modus) zum Einsatz kommen. Diese laufen dann direkt auf dem Gerät.

Vorteile: Volle Kontrolle über Umgebung, hohe Performance. Ein eingebauter lokaler Server könnte z. B. die Standard-Webschnittstelle bedienen. Auch statische Visualisierungen (Lagekarte auf Raspberri-Pi) lassen sich so offline realisieren. Updates können über Netzwerklaufwerke oder USB erfolgen.

Nachteile: Erhöhte Komplexität im Rollout (Installation auf vielen Systemen). Plattformspezifische Bindung (Windows-Umgebung vs. Linux-basierter Monitor). Abhängigkeiten auf die Hardware des Arbeitsplatzes (z. B. Grafikleistung).

Empfehlungen und kombinierte Modelle

In der Praxis ist häufig ein hybrides Modell sinnvoll, das mehrere Architekturen kombiniert. Beispielsweise könnte man eine gemeinsame Kernlogik (Service-Backend und Datenbank) haben, die über unterschiedliche Frontends angesprochen wird:

• Smartphone-Frontend: Eine mobile App (PWA oder native App) für die Datenerfassung vor Ort. Sie muss vollständig offlinefähig sein (Lokale DB, USB- Sync). Beispiele wie iKAT und rescueTABLET setzen auf native Apps mit Offline-Modus.
• Fahrzeug- und Stabs-Frontend: Ein Web- oder Desktop-Client für Führungskräfte zur Datenanalyse und Lagebewertung. Hier sind größere Bildschirme und Rechnerleistung verfügbar. Eine Browser-Anwendung (auch PWA) kann hier genutzt werden, da meist zumindest intermittierende Netzkonnektivität oder lokale Server (Laptop) bestehen.
• Lagebild-Anzeigen: Monitore in Leitstellen greifen meist auf Webinhalte zu (Browser-Kiosk oder Raspberry Pi). Diese können Daten vom Backend anzeigen, besonders Karten und Statusanzeigen.

Wichtig ist, dass alle Varianten das Offline-First-Paradigma unterstützen und Datenkonsistenz durch Versionierung und Konfliktauflösung gewährleisten. Letztlich zeigt sich: Eine kompromisslose Browser-Lösung allein ist unzureichend. Die Komplexität vieler Anforderungen (Offline-Autarkie, Hardwareintegration, Sicherheit) spricht für eine modulare Architektur – eine Mischung aus Web- und mobilen Nativen, ergänzt durch lokale Dienste. So kann man die Vorteile jeder Technologie nutzen: z. B. einen responsiven Web-Client für Stäbe und ein robustes mobiles Modul für Helfer im Feld.

In jedem Fall muss die gewählte Architektur die zentrale Forderung erfüllen: Zuverlässige Funktionsfähigkeit auch ohne durchgängige Netzverbindung.