🚒 Einsatzassistent

KI-gestütztes Lagebriefing + Objektdatenbank für die Feuerwehr

Der Einsatzassistent verwandelt die Anfahrtszeit in Vorbereitungszeit. Gruppenführer erhalten auf Basis des Alarmstichworts und hinterlegter Objektdaten ein taktisches Lagebriefing — bevor sie an der Einsatzstelle ankommen.

Hausbewohner können sicherheitsrelevante Daten über ihr Gebäude hinterlegen (PV-Anlage, Öltank, Sauerstoffpatient, Gefahrstoffe...), die im Einsatzfall den Kräften zur Verfügung stehen.

⚠️ Prototyp — Dieses Projekt befindet sich in aktiver Entwicklung. Die KI-generierten Briefings sind kein Ersatz für Ausbildung, Erfahrung und Erkundung vor Ort.

Warum?

Bei einer Alarmierung weiß der Gruppenführer bis zur Ankunft nur das Alarmstichwort der Leitstelle: Kellerbrand, Türöffnung dringend, VU Lage unklar. Feuerwehrpläne existieren nur für Sonderbauten — aber das normale Wohnhaus mit Öltank im Keller, PV-Anlage auf dem Dach und Sauerstoffpatient im Obergeschoss? Da fährt der GF blind hin.

Der Einsatzassistent schließt diese Lücke.

Features

🏠 Objektdatenbank

• Gebäudedaten erfassen: Bauweise, Stockwerke, Keller, Dach
• Energieversorgung: PV-Anlage, Batteriespeicher, Öltank, Gas
• Gefahren: Gefahrstoffe, Werkstatt, Druckgas, Munition
• Personen: Sauerstoffpatienten, Mobilitätseinschränkungen, Kinder
• Zugang: Zufahrten, Aufstellflächen, Schlüsseldepot, Hydranten
• Adresssuche, Import/Export als JSON
• Testdatensätze zum Ausprobieren

🚒 Einsatzassistent

• Alarmstichwort aus kategorisierter Liste wählen
• Adresseingabe mit automatischem Objekt-Lookup aus der Datenbank
• OpenStreetMap-Karte mit Geokodierung der Einsatzstelle
• KI-generiertes Lagebriefing mit:
  • Lagebewertung (objektspezifisch)
  • Gefahren (stichwortrelevante Objektdaten priorisiert)
  • Erstmaßnahmen (nach Priorität)
  • Erkundungsauftrag (Ja/Nein-Fragen)
  • Befehlsvorschlag (FwDV 3 Schema)
  • Funk-Beispiel (realistische Lagemeldung)
• Feedback-System: Briefings bewerten mit Tags und Kommentaren

📊 Feedback-Auswertung

• Dashboard mit Bewertungsstatistik pro Stichwort
• Schwachstellen im KI-Prompt identifizieren
• Export der Feedback-Daten als JSON

Quickstart

Mit Docker (empfohlen)

git clone https://github.com/DEIN-USER/einsatzassistent.git
cd einsatzassistent

# .env anlegen
cp .env.example .env
# Optional: Anthropic API-Key eintragen (ohne Key funktioniert die Objektdatenbank, aber keine Briefings)
nano .env

# Starten
docker compose up -d

# Öffnen: http://localhost:3000

Ohne Docker

git clone https://github.com/DEIN-USER/einsatzassistent.git
cd einsatzassistent
npm install

# Starten (ohne KI-Briefings)
node server.js

# Starten (mit KI-Briefings)
ANTHROPIC_API_KEY=sk-ant-... node server.js

Seiten

URL	Beschreibung
/	Startseite
/objektdaten.html	Objektdatenbank verwalten
/einsatz.html	Taktisches Lagebriefing
/feedback.html	Feedback-Auswertung
/api/health	Diagnose-Endpunkt

API

Objektdaten

Methode	Endpunkt	Beschreibung
GET	/api/objekte	Alle Objekte auflisten
GET	/api/objekte/:key	Einzelnes Objekt laden
PUT	/api/objekte/:key	Objekt speichern/aktualisieren
DELETE	/api/objekte/:key	Objekt löschen
DELETE	/api/objekte	Alle Objekte löschen
POST	/api/objekte/import	Bulk-Import (JSON Array)

Briefing

Methode	Endpunkt	Beschreibung
POST	/api/briefing	KI-Briefing generieren (Anthropic Proxy)

Feedback

Methode	Endpunkt	Beschreibung
GET	/api/feedback	Alle Bewertungen
POST	/api/feedback	Bewertung speichern
GET	/api/feedback/stats	Statistik pro Stichwort
DELETE	/api/feedback/:key	Einzelne Bewertung löschen

Export-Formate

Die Objektdaten lassen sich über /api/objekte als JSON abrufen und sind damit für externe Systeme (Leitstellen, Einsatzplanung) zugänglich. CSV/XML-Export ist auf der Roadmap.

Konfiguration

Umgebungsvariable	Beschreibung	Standard
ANTHROPIC_API_KEY	API-Key für KI-Briefings	— (ohne Key nur Objektdatenbank)
PORT	Server-Port	3000

Architektur

┌─────────────────────┐     ┌─────────────────────┐     ┌──────────────────┐
│  🏠 Objektdaten      │     │  🚒 Einsatz          │     │  📊 Feedback      │
│  objektdaten.html    │     │  einsatz.html        │     │  feedback.html   │
└────────┬────────────┘     └────────┬────────────┘     └────────┬─────────┘
         │                           │                            │
         └───────────┬───────────────┴────────────────────────────┘
                     │
              ┌──────┴──────┐
              │  Express    │
              │  REST API   │──── /api/briefing ───► Anthropic API
              │  server.js  │                        (oder Ollama)
              └──────┬──────┘
                     │
              ┌──────┴──────┐
              │ state.json  │
              │ (Dateisys.) │
              └─────────────┘

• Frontend: Vanilla React (via Babel Standalone, kein Build-Step)
• Backend: Express.js mit In-Memory-Store + File-Persistenz
• Karte: OpenStreetMap + Leaflet + Nominatim Geokodierung
• KI: Anthropic API (Claude) — perspektivisch auch Ollama (lokal)
• Daten: JSON-Datei (data/state.json), Volume-Mount in Docker

Designprinzipien

1. OpenSource (AGPL-3.0) — Kein Vendor-Lock-in. Jede Wehr kann es selbst betreiben.
2. Niedrige Einstiegshürde — Kein Account nötig für Dateneingabe. Formular so einfach wie möglich.
3. Leitstellen-kompatibel — REST-API als universelle Schnittstelle. CSV/XML-Export geplant. Perspektivisch UCRI/BosMon.
4. Minimale Kosten — Self-hosted, OSM statt Google Maps, Ollama als kostenlose KI-Option.

Berechtigungskonzept

Die Objektdatenbank enthält hochsensible Daten. "Bettlägeriger Senior, allein, Erdgeschoss links" ist nicht nur einsatzrelevant, sondern auch ein Einbruchsrisiko. Deshalb ist der Zugriff an konkrete Einsätze gekoppelt — ohne Alarmierung keine Daten.

Drei Säulen

1. Hausbesitzer-Portal (Dateneingabe)

Hausbewohner erfassen ihre Objektdaten über ein einfaches Webformular. Der Zugang erfolgt niedrigschwellig, z.B. per QR-Code auf einem Infoflyer der Feuerwehr. Jeder Hausbesitzer sieht und verwaltet nur seine eigenen Daten. Authentifizierung perspektivisch per Passkey — kein Passwort nötig.

2. Zugangssteuerung über die Leitstelle (Schleusenprinzip)

Die Leitstelle ist der Gatekeeper. Einsatzkräfte haben keinen dauerhaften Zugriff auf die Objektdaten. Erst wenn die Leitstelle einen Einsatz an einer Adresse disponiert, wird ein zeitlich begrenzter Zugangstoken erzeugt. Dieser Token ist an drei Bedingungen geknüpft:

• Adressbindung — gilt nur für das Objekt an der Einsatzadresse
• Zeitfenster — verfällt automatisch (z.B. 4 Stunden nach Alarmierung)
• Einheitsbindung — nur die disponierte Einheit kann die Daten abrufen

Technisch ist das ein JWT mit Adresse, Einheit und Ablaufzeit als Claims. Die Leitstelle erzeugt diesen Token automatisch beim Disponieren — kein manueller Schritt nötig.

┌──────────────┐     Disponiert Einsatz      ┌───────────────────┐
│              │  ──────────────────────────► │                   │
│  Leitstelle  │                              │  Zugangssteuerung │
│              │  ◄────────────────────────── │  (Token-Service)  │
└──────────────┘     Token (Adresse+Zeit)     └────────┬──────────┘
                                                       │
                     Token via MDT/App                 │
┌──────────────┐  ◄────────────────────────────────────┘
│              │
│ Gruppenführer│ ──── Fragt Objektdaten ab ──► ┌──────────────────┐
│ (Tablet/MDT) │                                │                  │
└──────────────┘  ◄── Daten nur bei gültigem ── │  Objektdatenbank │
                       Token entschlüsselt      │  (verschlüsselt) │
                                                └──────────────────┘

3. Audit-Trail (Nachvollziehbarkeit)

Jeder Datenzugriff wird protokolliert: wer hat wann welches Objekt abgefragt. Das ist DSGVO-Pflicht und schafft Vertrauen bei den Hausbewohnern, dass ihre Daten nicht "einfach so" einsehbar sind. Der Audit-Trail ist für den Datenschutzbeauftragten der Kommune einsehbar.

Umsetzungsstufen

Stufe	Beschreibung	Status
1. Prototyp	Alle Daten offen über API abrufbar. Kein Login. Zum Testen und Entwickeln.	✅ Aktuell
2. Basis-Auth	Login für Einsatzkräfte. Hausbewohner-Formular per QR-Code ohne Login. Admin-Rolle für Wehrführer.	🔲 Geplant
3. Leitstellen-Token	Zugriff nur mit gültigem Einsatz-Token. Automatische Erzeugung bei Disponierung. JWT-basiert.	🔲 Perspektivisch
4. Verschlüsselung	Objektdaten at-rest verschlüsselt. Entschlüsselung nur bei gültigem Token. Audit-Trail unveränderbar.	🔲 Perspektivisch

Hinweis: Im aktuellen Prototyp (Stufe 1) sind alle Daten ungeschützt über die API abrufbar. Nicht mit echten personenbezogenen Daten betreiben! Für den Übungsbetrieb und die Entwicklung mit Testdaten ist das ausreichend.

Roadmap

• Vereinfachtes Hausbewohner-Formular (QR-Code → 10-Fragen-Version)
• Ollama-Integration als kostenlose lokale KI-Alternative
• CSV/XML-Export für Leitstellen-Systeme
• Grundriss-/Bild-Upload pro Objekt
• Offline-fähige statische Einsatzkarten als KI-Fallback
• Anbindung an BOS-Übungsplattform
• Mobile-optimierte Ansicht für Tablets im Fahrzeug
• Zugangssteuerung (Rollen: Hausbewohner, Einsatzkraft, Admin)
• Leitstellen-Token-System (Zugriff nur bei aktiver Alarmierung)

Mitmachen

Siehe CONTRIBUTING.md für Details.

Kurzfassung: Issues und Pull Requests sind willkommen. Besonders gesucht:

• Einsatzkräfte die Briefings testen und Feedback geben
• Entwickler die bei Frontend, API oder Leitstellen-Integration helfen
• Feuerwehren die den Prototyp im Übungsbetrieb testen

Lizenz

AGPL-3.0 — Du darfst den Code nutzen, ändern und weitergeben, solange du Änderungen unter derselben Lizenz veröffentlichst. Das gilt auch für Server-Deployments (AGPL-Netzwerkklausel).

Hinweis

Dieses Projekt ist ein Prototyp. KI-generierte Briefings sind kein Ersatz für Ausbildung und Erfahrung. Alle taktischen Entscheidungen liegen beim Gruppenführer. Die Objektdaten werden von Hausbewohnern freiwillig bereitgestellt und können unvollständig oder veraltet sein.

---

Ein Projekt von tb-it.eu für die Feuerwehr.