BSFZ Forschungszulage – Projektantrag
Fintutto UG (haftungsbeschränkt)
Entwicklung einer offlinefähigen KI-Echtzeitübersetzungsplattform mit 4-Tier-Transportarchitektur
Experimentelle Entwicklung (Software)
FZulG-Antrag
STand: 26.3.2026
Gliederung des Antrags
Der vorliegende Antrag gliedert sich in drei zentrale Abschnitte, die gemeinsam den Forschungscharakter und die technologische Neuartigkeit des Vorhabens belegen.
01
Zielsetzung des Vorhabens
Problemstellung, Lösungsansatz und messbare Projektziele
02
Lösungsweg
Technologischer Ansatz und Entwicklungsphasen
03
Neuheitsgrad und Risiken
Stand der Technik, wissenschaftliche Neuheit und technische Unwägbarkeiten
Zielsetzung: Ausgangslage und Problemstellung
Bestehende Echtzeit-Übersetzungslösungen wie Google Translate oder DeepL setzen zwingend eine stabile Breitband-Internetverbindung voraus, da rechenintensive Machine-Learning-Modelle ausschließlich in der Cloud ausgeführt werden. Dieses Architekturprinzip führt zu einem systematischen Versagen in kritischen Anwendungsfällen:
🏔 Tourismus
Fehlende Mobilfunkabdeckung an abgelegenen touristischen Orten
🏛 Behörden
Restriktive Firewalls und IT-Sicherheitsrichtlinien in Amtsgebäuden
🏥 Medizin
Überlastete Krankenhausnetzwerke in Notaufnahmen
🎪 Events
Netzüberlastung bei Großveranstaltungen mit tausenden Teilnehmern
Zielsetzung: Das übergeordnete Forschungsziel
Forschungsziel
Entwicklung einer weltweit einzigartigen 4-Tier-Transportarchitektur, die Audio- und Textdaten in Echtzeit verarbeitet und dynamisch sowie nahtlos zwischen vier Netzwerkstufen wechselt — von der Cloud bis zur vollständigen Offline-Verarbeitung auf dem Endgerät.
Messbare Projektziele
Offline-Übersetzungslatenz von unter 1,5 Sekunden auf handelsüblichen Smartphones
Stabile BLE-Verbindung für bis zu 10 gleichzeitige Zuhörer ohne WLAN-Infrastruktur
Funktionsfähiger Prototyp aus einer einzigen Monorepo-Codebasis für mehrere Branchenvarianten
Die 4-Tier-Transportarchitektur im Überblick
Das Kernstück des Vorhabens ist eine neuartige Resilienz-Architektur, die vier Betriebsmodi hierarchisch orchestriert und automatisch zwischen ihnen wechselt.
Der automatische Fallback erfolgt nahtlos und für den Nutzer transparent — von der besten verfügbaren Verbindung bis zur vollständigen Geräteautarkie.
Tier 1 & 2: Cloud- und Hotspot-Modus
Tier 1 – Cloud-Modus
Bei stabiler Internetverbindung werden leistungsstarke Cloud-APIs (z. B. hochparametrische Übersetzungs- und Spracherkennungsmodelle) genutzt. Dies gewährleistet maximale Übersetzungsqualität und minimale lokale Rechenbelastung.
Tier 2 – Hotspot-Modus
Fällt die Internetverbindung aus, startet die App automatisch einen lokalen WebSocket-Server (Embedded Relay Server) auf dem Gerät des Sprechers. Zuhörer verbinden sich über einen lokalen WLAN-Hotspot. Übersetzungen erfolgen lokal im Netzwerk ohne Internetzugang — ideal für Gruppen in WLAN-geschützten Umgebungen.
Tier 3: Das BLE GATT Translation Protocol
Die technologisch anspruchsvollste Komponente: Ein proprietäres Protokoll auf Basis von Bluetooth Low Energy (BLE) Generic Attribute Profile (GATT) ermöglicht die synchrone 1-zu-N-Übertragung von Live-Übersetzungen — vollständig ohne jegliche Netzwerkinfrastruktur.
GATT-Server (Sprecher)
Das Gerät des Sprechers fungiert als zentraler GATT-Server, der übersetzte Daten aktiv an alle verbundenen Clients sendet.
GATT-Clients (Zuhörer)
Die Geräte der Zuhörer abonnieren die GATT-Characteristics des Servers und empfangen die Übersetzungsstreams passiv.
Chunking-Algorithmus
Da BLE primär für kleine IoT-Datenpakete konzipiert ist, muss ein spezieller Algorithmus entwickelt werden, der kontinuierliche Text- und Audio-Streams in BLE-kompatible Pakete zerlegt, überträgt und empfängerseitig latenzfrei reassembliert.
Tier 4: Vollständige On-Device-Übersetzung via WebAssembly
Offline-Modus (Tier 4)
Als letzte Fallback-Stufe werden vortrainierte Open-Source-ML-Modelle vollständig auf dem Endgerät ausgeführt — ohne jede externe Verbindung:
  • Opus-MT: Maschinelle Übersetzung (Text-zu-Text)
  • Whisper: Spracherkennung (Speech-to-Text)
Technologischer Ansatz
Die Ausführung erfolgt mittels WebAssembly (WASM) direkt im Browser des Endgeräts über Transformers.js. Dies erfordert eine hochoptimierte Modellquantisierung, um die Modelle (ca. 50–150 MB pro Sprache) performant auf Einsteiger-Smartphones lauffähig zu machen.
Ein intelligenter Caching-Mechanismus via IndexedDB stellt sicher, dass einmal geladene Modelle offline verfügbar bleiben, ohne den Arbeitsspeicher zu überlasten.
Lösungsweg: Drei iterative Entwicklungsphasen
Die Entwicklung erfolgt in drei aufeinander aufbauenden Phasen, die jeweils eine kritische technologische Herausforderung adressieren.
Jede Phase schließt mit definierten Testprotokollen und Leistungsmessungen ab, bevor die nächste Phase beginnt. Das agile Vorgehen erlaubt die iterative Anpassung an neu gewonnene Erkenntnisse aus Prototyp-Tests.
Lösungsweg: Technologiestack und Architekturentscheidungen
Die gesamte Entwicklung erfolgt in TypeScript unter Nutzung des React-Frameworks und des Build-Tools Vite. Die Codebasis ist als Turborepo (Monorepo) strukturiert, um mehrere Branchenvarianten effizient aus gemeinsamen Kernmodulen zu kompilieren.
TypeScript / React / Vite
Typsichere, komponentenbasierte Entwicklung mit schnellen Build-Zyklen für iteratives Prototyping
Turborepo (Monorepo)
Multi-Market-Architecture: Eine Codebasis generiert spezialisierte Varianten für Tourismus, Behörden, Medizin und Bildung
WebAssembly & Transformers.js
Browser-native ML-Inferenz mit nahezu nativer Rechenleistung ohne App-Store-Installation
Web Bluetooth API (BLE/GATT)
Hardwarenahe Kommunikation direkt aus dem Browser — ohne proprietäre native Schichten
Multi-Market-Architecture: Skalierung ohne linearen Aufwand
Herausforderung
Branchenspezifische Anforderungen (medizinisches Fachvokabular, behördliche Datenschutzrichtlinien, touristische Benutzerführung) erfordern stark differenzierte App-Varianten. Eine klassische Mehrfachentwicklung würde den Wartungsaufwand vervielfachen.
Lösung: Modulare Architektur
Durch die Monorepo-Struktur werden gemeinsame Kernmodule (ML-Pipeline, BLE-Stack, Netzwerk-Monitor) einmal entwickelt und gepflegt. Branchenspezifische Konfigurationen, UI-Varianten und Fachwortschätze werden als separate Packages überlagert — ohne Redundanz in der Kernlogik.
Neuheitsgrad: Stand der Technik und Alleinstellungsmerkmale
Das Vorhaben geht in drei zentralen Dimensionen signifikant über den aktuellen Stand der Technik hinaus und erfüllt damit die Kriterien der experimentellen Entwicklung gemäß Frascati-Handbuch.
1
BLE GATT Translation Protocol
Die synchrone 1-zu-N-Übertragung von Live-Übersetzungen via BLE existiert am Markt bisher nicht. Bestehende Systeme erfordern proprietäre Hardware oder gemeinsames WLAN. Die softwareseitige Lösung via Web Bluetooth ist eine Weltneuheit mit Patentpotenzial.
2
4-Tier Auto-Fallback-Architektur
Zwar bieten einzelne Apps Offline-Übersetzungen (z. B. Google Translate), doch kein System wechselt dynamisch und unterbrechungsfrei zwischen Cloud, lokalem Hotspot, Bluetooth und reinem On-Device-Modus. Diese Resilienz-Architektur ist neuartig.
3
WASM-Spracherkennung im mobilen Browser
Die Ausführung von Whisper-Modellen zur Spracherkennung direkt im mobilen Browser — ohne native App-Installation — stellt die Grenzen aktueller Webtechnologie dar und ist in dieser Form kommerziell noch nicht verfügbar.
Technische Risiken und Unwägbarkeiten
Das Vorhaben birgt erhebliche technische Entwicklungsrisiken im Sinne des Frascati-Handbuchs, die den FuE-Charakter eindeutig belegen.
⚡ Performance-Risiko (WASM)
Es ist ungeklärt, ob ältere Smartphones die quantisierten ML-Modelle in Echtzeit (Latenz < 1,5 s) ausführen können, ohne thermische Probleme oder kritischen Akkuverbrauch zu verursachen. Systematisches Benchmarking auf Referenzgeräten ist erforderlich.
📡 Bandbreiten-Risiko (BLE)
Die inhärent limitierte Bandbreite von BLE gefährdet die Stabilität des Chunking-Algorithmus bei vielen gleichzeitigen Zuhörern oder bei Audio-Streams (TTS). Paketverluste und Latenzzunahmen müssen durch Protokollforschung minimiert werden.
🔧 Kompatibilitäts-Risiko
Die Web Bluetooth API wird von iOS Safari bislang nicht unterstützt. Die Entwicklung von Workarounds via Capacitor oder nativen Bridges erhöht den Aufwand unvorhersehbar und erfordert plattformspezifische Forschung.
FuE-Charakter: Einordnung nach FZulG
Experimentelle Entwicklung gemäß FZulG
Das Vorhaben erfüllt die Kriterien der experimentellen Entwicklung nach § 2 Abs. 4 FZulG: Es werden systematisch neue Kenntnisse erarbeitet, um technische Unwägbarkeiten zu überwinden, die mit dem aktuellen Stand von Wissenschaft und Technik nicht lösbar sind — ohne Forschungsaufwand wäre das Projektziel nicht erreichbar.
Frascati-Kriterien im Überblick
Neuheit: Drei weltweit neuartige Technologiebeiträge (BLE-Protokoll, 4-Tier-Fallback, WASM-ASR im Browser)
Kreativität: Neuartige Kombination von Browser-APIs, ML-Modellen und hardwarenahen Protokollen
Ungewissheit: Performance-, Bandbreiten- und Kompatibilitätsrisiken ohne bekannte Lösung
Systematik: Strukturierter 3-Phasen-Entwicklungsplan mit definierten Testprotokollen
Zusammenfassung und Projektziele
Das Forschungsvorhaben der Fintutto UG adressiert eine technologisch bedeutsame Lücke: die zuverlässige, offlinefähige Echtzeit-Übersetzung für kritische Anwendungsumgebungen ohne stabile Internetverbindung.
4
Netzwerktiers
Cloud, Hotspot, BLE, Offline — nahtlos orchestriert
<1.5s
Ziellatenz
Offline-Übersetzung auf Endgerät
10
BLE-Zuhörer
Gleichzeitig ohne WLAN-Infrastruktur
3
Weltneuheiten
BLE-Protokoll, 4-Tier-Fallback, WASM-ASR

Das Vorhaben erfüllt alle Kriterien der experimentellen Entwicklung nach FZulG § 2 Abs. 4 und ist förderungswürdig im Sinne des Forschungszulagengesetzes.