GIS Care — Architektur & Konzepte

1. App-Architektur (Flutter)

GIS Care folgt einer MVVM-Architektur (Model - View - ViewModel) mit Riverpod als State-Management-Lösung.

lib/
├── main.dart                    # App-Entry-Point
├── app.dart                     # MaterialApp + Routing
├── models/                      # Datenmodelle
│   ├── emergency_contact.dart
│   └── sensor_data.dart
├── services/                    # Business-Logik / API-Kommunikation
│   ├── config_sync_service.dart # Server-Config → App-State
│   ├── api_service.dart         # HTTP-Client für Server-API
│   └── ...
├── viewmodels/                  # Riverpod StateProvider / StateNotifier
│   ├── server_config_providers.dart   # Alle serverseitig gesteuerten Optionen
│   ├── lone_worker_providers.dart     # Schutz-Logik, Alarme, Szenarien
│   └── ...
├── views/                       # UI-Screens (Seiten)
│   ├── lone_worker_page.dart
│   ├── settings_page.dart
│   └── ...
├── widgets/                     # Wiederverwendbare UI-Komponenten
├── theme/                       # Theming (Dark/Light)
└── utils/                       # Hilfsfunktionen

State-Management

Alle server-gesteuerten Einstellungen werden über Riverpod StateProvider in server_config_providers.dart gehalten. Der ConfigSyncService schreibt die Serverwerte beim Login und periodisch in diese Provider. Views und ViewModels lesen sie per ref.watch() / ref.read().

Prinzip: Der Server ist Single Source of Truth für alle Konfigurationen. Die App hat Standardwerte als Fallback, überschreibt diese aber sofort nach dem Sync.

2. Konfigurationssystem

Das Konfigurationssystem verbindet Admin-Panel, Server-Datenbank und Flutter-App in einer durchgängigen Pipeline:

Admin-Panel (admin.js) │ CONFIG_META definiert Labels, Beschreibungen, Tooltips │ Benutzer ändert Werte → saveAllConfig() ▼ Server-API (config.php) │ POST /api/config.php?action=set_bulk │ Schreibt in DB-Tabelle `app_config` ▼ Datenbank (app_config) │ config_group | config_key | config_value | value_type │ Gruppiert: general, sensor, protection, alarm, ui, branding, dguv ▼ App-Sync (config_sync_service.dart) │ GET /api/config.php?action=app_sync │ _applyConfig() → schreibt in Riverpod StateProvider ▼ Flutter-App (server_config_providers.dart) │ ref.watch(showSensorsTabProvider) → UI passt sich an │ ref.read(storeGpsOnAlarmProvider) → Alarm-Logik

Konfigurations-Gruppen (Tabs im Admin-Panel)

Gruppe	Tab-Name	Zweck
`general`	🏢 Allgemein	App-Name, Version, Firmenname, Sprache, Heartbeat
`sensor`	📡 Sensoren	Abtastrate, Zeitfenster, Datenpunkte
`protection`	🛡️ Schutz	Profil, Berechtigungen, Schutzzwang
`alarm`	🚨 Alarm	Server-Meldung, GPS, Sensordaten bei Alarm
`ui`	🎨 Oberfläche	Dark Mode, Tab-Sichtbarkeit, Startseite
`branding`	🎨 Branding & Impressum	Logo, Berichte, Firmendaten, Impressum
`dguv`	📋 DGUV	Akku-Warnung, Funktionsprüfung, Schichtdauer

3. Konfigurationsschlüssel (Referenz)

Übersicht aller Konfigurationsschlüssel mit ihrem Status:

🏢 Allgemein

Key	Typ	Status	Beschreibung
`app_name`	string	Server-only	Name der Anwendung
`app_version`	string	Server-only	Aktuelle App-Version
`company_name`	string	Server-only	Firmenname
`default_language`	string	Server-only	Standard-Sprache
`heartbeat_interval_sec`	int	Aktiv	Heartbeat-Intervall (Sekunden)

📡 Sensoren

Key	Typ	Status	Beschreibung
`default_sampling_rate`	string	Aktiv	Abtastrate (fastest/game/ui/normal)
`default_graph_window`	int	Aktiv	Diagramm-Zeitfenster (Sekunden)
`max_data_points`	int	Geplant	Max. Datenpunkte im Speicher
`auto_start_sensors`	bool	Geplant	Sensoren beim App-Start starten

🛡️ Schutz

Key	Typ	Status	Beschreibung
`default_profile_id`	int	Server-only	Standard-Schutzprofil-ID
`allow_profile_change`	bool	Aktiv	Benutzer darf Profil wechseln
`force_protection_on`	bool	Aktiv	Schutz kann nicht deaktiviert werden
`allow_threshold_change`	bool	Aktiv	Benutzer darf Schwellwerte anpassen
`allow_scenario_toggle`	bool	Aktiv	Benutzer darf Szenarien umschalten

🚨 Alarm

Key	Typ	Status	Beschreibung
`send_to_server`	bool	Aktiv	Alarme an Server melden
`store_gps_on_alarm`	bool	Aktiv	GPS-Position bei Alarm speichern
`store_sensor_data`	bool	Aktiv	Sensordaten bei Alarm mitsenden
`max_alarm_history`	int	Geplant	Max. lokale Alarm-Historie

🎨 Oberfläche

Key	Typ	Status	Beschreibung
`dark_mode_default`	bool	Aktiv	Dark Mode als Standard
`show_sensors_tab`	bool	Aktiv	Sensoren-Tab anzeigen
`show_analysis_tab`	bool	Aktiv	Analyse-Tab anzeigen
`show_dashboard_tab`	bool	Aktiv	Dashboard-Tab anzeigen
`show_settings_details`	bool	Aktiv	Technische Einstellungen anzeigen
`start_page`	string	Aktiv	Startseite (protection/dashboard)
`show_sensor_details`	bool	Geplant	Erweiterte Sensorinfos
`enable_export`	bool	Geplant	Datenexport erlauben
`enable_recording`	bool	Geplant	Aufzeichnung erlauben

🎨 Branding & Impressum

Key	Typ	Status	Beschreibung
`logo_url`	string	Server-only	URL zum Firmenlogo
`report_header`	string	Server-only	Kopfzeile für PDF-Berichte
`report_footer`	string	Server-only	Fußzeile für PDF-Berichte
`company_address`	string	Server-only	Firmenadresse
`company_phone`	string	Server-only	Firmentelefon
`company_email`	string	Server-only	Firmen-E-Mail
`company_website`	string	Server-only	Webseite
`impressum_*`	string	Server-only	Impressum-Pflichtangaben (§5 TMG)

📋 DGUV 112-139

Key	Typ	Status	Beschreibung
`battery_warning_threshold`	int	Aktiv	Akku-Warnschwelle in % (§4.5)
`require_functional_test`	bool	Aktiv	Funktionsprüfung erforderlich (§4.7)
`max_shift_duration_hours`	int	Aktiv	Max. Schichtdauer in Stunden (§4.8)
`alarm_response_timeout_sec`	int	Aktiv	Reaktionszeit Empfangszentrale (§4.3)
`dguv_compliance_mode`	bool	Aktiv	DGUV-Konformitätsmodus (Master-Toggle)

Hinweis: Keys mit Status Geplant sind im Admin-Panel konfigurierbar, werden aber noch nicht von der App ausgewertet. Sie sind für zukünftige Funktionen vorgesehen.

4. Alleinarbeiterschutz-Szenarien

GIS Care erkennt Gefahrensituationen durch verschiedene Sensor-Szenarien:

Szenario	Sensor	Auslöser	DGUV-Bezug
🔻 Sturzerkennung	Beschleunigungssensor	Plötzliche Beschleunigungsspitze + Aufprallmuster	§4.4 Personennotsignal
😴 Bewusstlosigkeit	Beschleunigungssensor	Keine Mikro-Bewegungen über einstellbare Dauer	§4.4 Personennotsignal
⏸️ Bewegungslosigkeit	Schrittzähler	Keine Schritte über einstellbare Dauer	§4.4 Personennotsignal
📐 Lageänderung	Beschleunigungssensor	Dauerhafte Neigungsänderung (liegend)	§4.4 Personennotsignal
💓 Check-in	—	Benutzer meldet sich nicht innerhalb des Intervalls	§4.2 Zeitüberwachung
🆘 Manueller SOS	—	Benutzer drückt den SOS-Button	§4.1 Willensabhängig
📡 Verbindungsverlust	Netzwerk	Heartbeat erreicht Server nicht	§4.6 Kommunikationsweg

Schutzprofile

Ein Schutzprofil bündelt die Konfiguration aller Szenarien: welche aktiv sind, Schwellwerte, Empfindlichkeit und Verzögerungen. Profile werden zentral im Admin-Panel verwaltet und den Benutzern zugewiesen.

5. DGUV 112-139 Konformität

GIS Care implementiert die Anforderungen der DGUV 112-139 (Einsatz von Personen-Notsignal-Anlagen):

DGUV-Paragraph	Anforderung	Umsetzung in GIS Care
§4.1	Willensabhängige Auslösung	Manueller SOS-Button in der App
§4.2	Zeitgesteuerte Überwachung	Check-in / Heartbeat-Szenario
§4.3	Zeitnahe Quittierung	`alarm_response_timeout_sec` (Standard: 120s)
§4.4	Willensunabhängige Auslösung	Sturz-, Bewusstlosigkeits-, Lageerkennungs-Szenarien
§4.5	Energieversorgung überwachen	`battery_warning_threshold` (Standard: 20%)
§4.6	Kommunikationsweg sichern	Verbindungsverlust-Erkennung + Heartbeat
§4.7	Funktionsprüfung vor Benutzung	`require_functional_test` vor jeder Schicht
§4.8	Schichtdauer begrenzen	`max_shift_duration_hours` (Standard: 8h)

Alarme und Heartbeats dürfen NIEMALS stille Fallbacks haben.
Jeder fehlgeschlagene Alarm oder Heartbeat muss als Fehler gemeldet werden — keine Unterdrückung, kein try/catch ohne Logging.

6. Alarm-Ablauf

Wenn ein Szenario auslöst, durchläuft der Alarm folgende Stufen:

Szenario-Erkennung (z.B. Sturz) ▼ Eskalationskette (configurable per Profil): 1. Warnung → App-Vibration + Ton (30s Reaktionszeit) 2. Kritisch → Push-Benachrichtigung (60s) 3. Notfall → Server-Alarm + GPS + Sensordaten ▼ Server empfängt Alarm (POST /api/alarms.php) ├── Speichert in DB (alarms-Tabelle) ├── GPS-Position (wenn store_gps_on_alarm = true) ├── Sensordaten-Snapshot (wenn store_sensor_data = true) └── Benachrichtigt Admin-Panel (Live-Polling) ▼ Admin/Customer-Admin quittiert Alarm └── Reaktionszeit wird gemessen (alarm_response_timeout_sec)

Entwarnung

Der Benutzer kann einen Alarm jederzeit vor der Eskalation abbrechen. Abgebrochene Alarme werden als Entwarnung gespeichert und im Admin-Panel mit ✅ markiert.

7. Sicherheitskonzept

Authentifizierung

JWT-basierte Token-Authentifizierung
Token-Refresh bei jedem API-Aufruf
Sichere Passwort-Hashes (bcrypt)

Mandantentrennung

Alle Abfragen filtern nach users.customer_id
customer_admin sieht nur Daten des eigenen Kunden
Kein Cross-Tenant-Zugriff möglich

Datenschutz

GPS-Daten nur bei Alarm (konfigurierbar via store_gps_on_alarm)
Sensordaten-Speicherung konfigurierbar via store_sensor_data
Impressum-Pflichtangaben verwaltbar im Admin-Panel

API-Absicherung

Alle API-Endpunkte erfordern Authentifizierung (requireAuth())
Admin-Endpunkte erfordern requireAdmin()
CORS-Header konfiguriert
API-Timeout: 15 Sekunden

🏗️ Architektur & Konzepte

1. App-Architektur (Flutter)

State-Management

2. Konfigurationssystem

Konfigurations-Gruppen (Tabs im Admin-Panel)

3. Konfigurationsschlüssel (Referenz)

🏢 Allgemein

📡 Sensoren

🛡️ Schutz

🚨 Alarm

🎨 Oberfläche

🎨 Branding & Impressum

📋 DGUV 112-139

4. Alleinarbeiterschutz-Szenarien

Schutzprofile

5. DGUV 112-139 Konformität

6. Alarm-Ablauf

Entwarnung

7. Sicherheitskonzept

Authentifizierung

Mandantentrennung

Datenschutz

API-Absicherung