Eine Drohne, die eine Offshore-Windanlage wartet, empfängt keine Wünsche. Sie bekommt Befehle: Koordinaten, Höhen, Sequenzen, Abbruchbedingungen. Wer diese Befehle heute gibt, schreibt sie von Hand, für genau diese eine Anlage.
Die Barra Technologies GmbH aus Berlin erforscht, ob ein Sprachmodell diesen Schritt übernehmen kann. Aus einer abstrakt beschriebenen Mission werden Steuerbefehle. Wenn die Übersetzung stimmt.
Jede Drohne ein eigenes Projekt
Wer Drohnen in industrielle Abläufe integrieren will, startet bislang ein Softwareprojekt. Individuell, aufwendig, kaum wiederverwendbar. Die Anbindung an die ERP-Prozesse wird jedes Mal neu gebaut, mit langen Entwicklungszeiten und hohen Integrationskosten.
Eine generische Lösung existiert nicht. Es gibt keine Software, die missionskritische Logik in ERP-nahe Prozesse integriert und gleichzeitig nativ mit autonomen Drohnen kommuniziert. Genau diese Lücke adressiert das Vorhaben mit einer modularen, domänenspezifisch erweiterbaren Architektur statt einer weiteren Speziallösung.
Barra Technologies: Software-Architektur aus Berlin
Die Barra Technologies GmbH sitzt in der Strelitzer Straße in Berlin-Mitte, mit einem zweiten Standort in München. Das Haus entwickelt Software- und Architekturlösungen für Kunden verschiedener Branchen — mit einem Anspruch auf Systeme, die skalieren und lange tragen.
Seit November 2024 läuft parallel dazu ein Forschungsvorhaben, das über Auftragsarbeit hinausgeht: eine generische Plattformarchitektur für autonome Drohneneinsätze. 156,6 Personenmonate, 25 Mitarbeitende im Unternehmen, komplett aus eigenen Mitteln finanziert.
Eine Sprache für Missionen
Der Kern der Architektur ist eine domänenspezifische Sprache. Statt jede Mission auszuprogrammieren, wird sie abstrakt beschrieben — auf einer Ebene, die Fachleute aus Offshore-Wartung, Logistik oder Landwirtschaft formulieren können, ohne Flugsoftware zu schreiben.
Ein Sprachmodell übersetzt diese Beschreibung zur Build- und zur Laufzeit in drohnenverständliche Befehlssequenzen und übermittelt sie an die Ground-Control-Station. Die Anbindung läuft über MAVLink, REST und TCP; Air- und Ground-Module hängen über eine gemeinsame Schnittstelle zusammen.
Sieben Meilensteine strukturieren die Arbeit: vom Lightweight-ERP-Prototyp über das lesende und schreibende Drohnen-ERP bis zur KI-gestützten Missionsorchestrierung, die domänenspezifische Anforderungen dynamisch in Befehle umwandelt.
Die Nachforderung entschied
Im Oktober kam die Nachforderung. Für viele Antragsteller ist das der Moment, in dem sie mit einer Ablehnung rechnen. Tatsächlich ist es der Moment, in dem die Bescheinigungsstelle noch nicht überzeugt ist, aber überzeugt werden will.
Die Begründung des Bescheids sagt das ungewöhnlich deutlich. Zur Neuartigkeit hält die BSFZ fest, die grundlegenden Ziele seien „in der Antwort auf die Nachforderung nachvollziehbar beschrieben" worden und erst „anhand der nachgereichten Informationen" sei der Erwerb neuer Kenntnisse erkennbar. Beim Kriterium Risiko verweist sie ebenfalls ausdrücklich auf die nachgereichten Ausführungen.
Banhoek Consulting formulierte diese Antwort. Entscheidend war, die Neuartigkeit nicht im Einsatz von Sprachmodellen zu verorten, sondern in der abstrahierten Missionsmodellierung und der generischen, erweiterbaren Plattformarchitektur — und die Risiken so konkret zu benennen, dass die Bescheinigungsstelle sie in ihrer eigenen Begründung zitieren konnte. Der Bescheid kam zwei Wochen später.
Warum Risiken der stärkste Teil eines Antrags sind
Viele Unternehmen schreiben Anträge wie Verkaufsprospekte. Alles funktioniert, alles ist durchdacht, alles wird klappen. Das ist der sicherste Weg zur Ablehnung — denn ohne Unwägbarkeit gibt es keine Forschung, sondern nur Entwicklung.
Ob sich Multi-Stakeholder-Prozesse überhaupt standardisiert und ausfallsicher abbilden lassen, ist offen. Die Bescheinigungsstelle griff die Formulierung von den „instabilen oder unbrauchbaren Kommandosequenzen" auf und erklärte das Kriterium der Unwägbarkeit für erfüllt.
