Sensoren in ATAK integrieren: vom Entfernungsmesser bis zum SDR-Empfänger

Ein Entfernungsmesser kennt die Distanz zu einem Ziel. Ein Funkgerät kennt die Teilnehmer im Netz. Ein SDR-Empfänger kennt die aktiven Frequenzen und den Standort der Sender. Dieses Wissen ist solange wertlos, bis es als geteiltes, zeitgestempeltes Objekt auf der Karte des Bedieners erscheint, das das gesamte Team sehen und nutzen kann. Diese Übersetzung – von einer Rohdatenmessung zu einem Marker im Common Operating Picture – ist genau das, was ein gut gebautes ATAK-Sensorintegrations-Plugin leistet. Dieser Artikel erläutert die Muster zur Verbindung von Feldsensoren mit ATAK, zur Normalisierung ihrer sehr unterschiedlichen Ausgaben und zur Veröffentlichung sauberer Detektionen im COP, ohne es mit Rauschen zu überschwemmen.

Das Integrationsproblem: viele Sensoren, ein Lagebild

Feldsensoren sind nicht auf Interoperabilität ausgelegt. Ein Laserentfernungsmesser gibt Entfernung, Azimut und Neigung über ein Bluetooth-Serielle-Profil in einem eigenen proprietären Satzformat aus. Ein taktisches Funkgerät stellt Positionsmeldungen und Netzzugehörigkeit über eine softwaredefinierte Schnittstelle oder ein serielles Gateway bereit. Ein SDR-Empfänger erzeugt Peilungen und Signalklassifikationen als Strom strukturierter Datensätze über einen Netzwerk-Socket. Jeder nutzt einen anderen Transport, eine andere Rahmung, ein anderes Einheitensystem und eine andere Koordinatenkonvention.

ATAK stellt das bereit, was sie alle benötigen: ein gemeinsames räumlich-zeitliches Datenmodell. Jedes Objekt auf der ATAK-Karte ist ein Cursor on Target (CoT)-Ereignis – eine XML-Nachricht, die beschreibt, was beobachtet wurde, wo, wann und mit welcher Konfidenz. Die Aufgabe eines Sensor-Plugins ist daher eng und klar definiert: die native Ausgabe des Sensors empfangen, sie in eine kanonische Messung normalisieren, diese Messung in ein oder mehrere CoT-Ereignisse umwandeln und diese Ereignisse in den internen Bus von ATAK einspeisen. Sobald eine Messung ein CoT-Ereignis ist, rendert ATAK es, speichert es und föderiert es über TAK Server an jeden verbundenen Client – ohne weitere Plugin-Beteiligung.

Diese Pipeline korrekt zu gestalten, erfordert vor allem Disziplin an den Grenzen. Die Sensorseite ist unübersichtlich und gerätespezifisch; die CoT-Seite ist einheitlich. Ein gutes Plugin hält diese beiden Welten durch eine Normalisierungsschicht streng getrennt, sodass die Unterstützung eines neuen Sensors das Schreiben eines Adapters bedeutet – und nicht die Überarbeitung des Veröffentlichungspfads.

Plugin-Architektur: die drei Schichten

Ein produktionsreifes Sensorintegrations-Plugin gliedert sich sauber in drei Schichten, jede mit einer einzigen Verantwortung.

1. Die Sensor-Dienst-Schicht. Diese Schicht besitzt die physische oder logische Verbindung zum Gerät. Bei einem Bluetooth-Entfernungsmesser verwaltet sie den seriellen Port-Profil-Socket; bei einem USB-Gerät verwendet sie die Android-USB-Host-API mit einem USB-Seriell-Treiber; bei einer SDR-Bridge hält sie einen TCP-Client zu einem Begleit-Computer. Die Grundregel dieser Schicht lautet: Sie berührt niemals den UI-Thread. Die gesamte Geräte-E/A läuft in einem dedizierten Hintergrund-Thread oder einem Android-Service, strukturiert als explizite Verbindungs-/Lese-/Wiederverbindungs-/Trennungs-Zustandsmaschine. Rohe Bytes werden zu diskreten Messungen gerahmt und weitergeleitet – hier werden sie nur auf ihre Grenzen hin analysiert, nicht inhaltlich ausgewertet.

2. Die Normalisierungsschicht. Jeder Sensortyp verfügt über einen Adapter, der seine Rohmessung in ein einziges internes Messmodell umwandelt. Dieses Modell verwendet durchgehend feste Einheiten: WGS84-Grad für Position, Meter für Entfernung und Höhe, Grad nach Rechtsnord für Azimut und UTC für Zeitstempel. Der Adapter führt Einheitenumrechnungen durch (Strich zu Grad, magnetisch zu wahrem Kurs mit einem Deklinationsmodell), Datumstransformationen, wenn das Gerät in einem Nicht-WGS84-Datum berichtet, und Konfidenzschätzungen. Alles Nachgelagerte verarbeitet nur das normalisierte Modell – das macht die Architektur erweiterbar.

3. Die CoT-Veröffentlichungsschicht. Diese Schicht bildet normalisierte Messungen auf Cursor on Target-Ereignisse ab und speist sie in ATAK ein. Sie entscheidet über die Ereignisgeometrie (Punkt, Linie oder Polygon), den CoT-Typcode, die UID-Strategie für verfolgte gegenüber einmaligen Messungen und die Verfallszeit. Sie ist die einzige Schicht, die die APIs von ATAK kennt, was Sensor- und Normalisierungsschicht portabel und unabhängig testbar hält.

Warum die Normalisierungsschicht ihren Platz verdient

Es ist verlockend, bei der Integration eines einzelnen Sensors die Normalisierung zu überspringen und die Geräteausgabe direkt in CoT umzuwandeln. Diese Abkürzung bricht in dem Moment zusammen, in dem ein zweiter Sensor hinzukommt – und im Feld gibt es immer einen zweiten Sensor. Mit einem expliziten Messmodell leben die Deklinationskorrektur, die Datum-Behandlung und die Konfidenzlogik an einem Ort und werden einmal unit-getestet. Das Hinzufügen eines neuen Entfernungsmessermodells wird zu einem 100-Zeilen-Adapter, und eine völlig neue Sensorklasse wird zu einem neuen Adapter plus einer einzigen neuen CoT-Abbildungsregel. Ohne diese Trennung zieht jedes neue Gerät Änderungen durch den Veröffentlichungspfad und gefährdet die bereits funktionierenden Sensoren.

Entfernungsmesser: der kanonische Punktsensor

Ein Laserentfernungsmesser ist die einfachste und häufigste ATAK-Sensorintegration und setzt die Vorlage für alles andere. Der Bediener nimmt eine Laserentfernungsmessung vor; das Gerät meldet Schrägentfernung, magnetischen Azimut und Neigungswinkel. Kombiniert mit der eigenen Position des Bedieners aus dem GPS von ATAK lösen diese drei Zahlen eine einzige Zielkoordinate auf.

Die Geometrie ist eine Polar-zu-Kartesisch-Projektion vom Standort des Bedieners: den magnetischen Azimut durch Anwendung der lokalen Deklination in den wahren Azimut umwandeln, die Schrägentfernung über den Neigungswinkel in eine Bodenentfernung und ein Höhendelta projizieren und vom bekannten Sensorstandort aus die WGS84-Koordinate des Ziels berechnen. Das Ergebnis wird als CoT-Punktereignis mit einer feindlichen, freundlichen oder unbekannten Zugehörigkeit veröffentlicht, die der Bediener wählt, und einer Verfallszeit, die lang genug ist, um nützlich zu sein, aber kurz genug, dass eine aufgegebene Messung nicht dauerhaft auf der Karte bleibt.

Zwei Implementierungsdetails verursachen die meisten Feldausfälle. Das erste ist die Deklination: Ein Entfernungsmesser meldet einen magnetischen Kurs, und seine Verwendung als wahrer Kurs erzeugt einen Zielfehler, der mit der Entfernung wächst – bei 5 km platziert eine unkorrekte Deklination von wenigen Grad den Marker Hunderte von Metern daneben. Das Plugin muss ein Deklinationsmodell für den Standort und das Datum des Bedieners anwenden. Das zweite ist die Bluetooth-Leseschleife: Entfernungsmesser koppeln über das serielle Port-Profil und senden pro Schuss einen Satz, aber wenn das Lesen im UI-Thread läuft, ruckelt die gesamte ATAK-Oberfläche bei jeder Wiederverbindung des Geräts. Das Lesen muss im Hintergrund-Sensor-Dienst laufen.

Funkgeräte: Positionsmeldungen und Netzwerkzustand

Taktische Funkgeräte tragen zwei Arten von Daten zum Lagebild bei: die Positionen der Funkgeräte selbst und den Zustand des Netzes. Moderne softwaredefinierte Funkgeräte und datenfähige Handgeräte stellen Positionsmeldungen über ein serielles oder IP-Gateway bereit, und das Integrationsmuster spiegelt die umfassendere Praxis der Verbindung taktischer Funkgeräte mit Software wider. Jede Meldung wird zu einem CoT-Positionsereignis mit einer stabilen UID, die aus der Kennung des Funkgeräts abgeleitet wird, sodass ATAK einen sich bewegenden Freundmarkierer anzeigt, anstatt eine Reihe unzusammenhängender Punkte.

Der Netzwerkzustand ist der subtilere Beitrag. Ob ein Knoten erreichbar ist, welche Verbindungsqualität er hat und wann er zuletzt gemeldet hat – all das ist operativ bedeutsam. Ein leistungsfähiges Funkgeräte-Plugin stellt dies als Markerstil dar – ein Knoten, der innerhalb seines erwarteten Intervalls nicht gemeldet hat, wird visuell gealtert oder ausgegraut – und optional als CoT-Detailfeld, damit nachgelagerte Tools über den Verbindungszustand schlussfolgern können. Das Plugin sollte niemals einen veralteten Knoten direkt löschen; es sollte die CoT-Verfallszeit nutzen, um Unsicherheit auszudrücken, damit der Bediener den Unterschied zwischen „bestätigt verschwunden" und „zuletzt nicht gehört" versteht.

SDR-Empfänger: Peilungen, Positionen und das Begleit-Computer-Muster

Softwaredefinierte Funkempfänger sind die anspruchsvollste Sensorklasse zur Integration, da die aufwändige Signalverarbeitung selten auf dem Android-Gerät selbst läuft. Das Standard-Einsatzszenario platziert die SDR-Plattform und ihre Erkennungs- oder Peilungs-Pipeline auf einem Begleit-Computer, wobei das ATAK-Plugin als schlanker Verbraucher über einen lokalen Netzwerk-Socket fungiert.

Die SDR-Pipeline erzeugt drei nützliche Produkttypen. Eine einzelne Peilungsmessung wird auf eine CoT-Linie abgebildet, die vom Sensorstandort entlang des gemessenen Azimuts gezogen wird, optional mit einem Winkelunsicherheits-Keil. Eine Mehrfachsensor- oder Bewegungsbasislinie-Position wird auf einen CoT-Punkt mit einer Fehlerellipse abgebildet, die die Geolokalisierungskonfidenz ausdrückt. Eine Signalklassifikation – Emittertyp, Modulation, Frequenz – wird als CoT-Detail angehängt, sodass der Bediener nicht nur sieht, wo sich ein Emitter befindet, sondern auch, was er wahrscheinlich ist. Da die SDR-Seite asynchron und mit hoher Rate läuft, muss das Plugin vor der Veröffentlichung drosseln und deduplizieren; ein roher Peilungsstrom mit Dutzenden Hertz würde sowohl die Karte als auch die TAK Server-Förderation überlasten.

Im COP veröffentlichen, ohne es zu überfluten

Sobald Messungen normalisiert sind, entscheidet die Disziplin der Veröffentlichungsschicht darüber, ob das Plugin hilft oder schadet. Drei Regeln bestimmen gutes Verhalten. Erstens: Weisen Sie allem, was verfolgt werden soll – einem Funkgerät, einem persistenten Emitter – eine stabile UID zu, damit Aktualisierungen den bestehenden Marker ersetzen, anstatt neue zu erzeugen; weisen Sie eine neue UID nur echten unabhängigen Einmalereignissen wie einem einzelnen Laser-Schuss zu. Zweitens: Passen Sie die CoT-Verfallszeit an die Konfidenz an: Ein bestätigter, wiederholt beobachteter Track kann eine Minute oder länger bestehen bleiben, während eine einzelne unsichere Detektion innerhalb von Sekunden verfallen sollte, damit sie sich selbst löscht. Drittens: Deduplizieren und drosseln Sie an der Quelle, bevor das Ereignis den Bus erreicht, damit die Förderation Signal statt Rauschen überträgt.

Ebenso wichtig ist Ehrlichkeit über den Verbindungszustand. Ein Feldsensor-Plugin muss davon ausgehen, dass das Netzwerk – und manchmal die Sensorverbindung selbst – ausfällt. Messungen werden in dem Moment, in dem sie aufgenommen werden, in eine lokale Warteschlange geschrieben, mit der Erfassungszeit statt der Veröffentlichungszeit gestempelt, und bei Wiederherstellung der Konnektivität als CoT geleert. Das Plugin-Panel sollte immer den Sensorverbindungsstatus, das Alter der letzten Messung und etwaige Veröffentlichungsrückstände anzeigen. Ein Plugin, das stillschweigend aufhört zu aktualisieren, wenn ein Sensor die Verbindung trennt, ist schlimmer als gar kein Plugin, weil es ein veraltetes Lagebild als aktuelles darstellt. Dieselbe Offline-Disziplin gilt unabhängig davon, ob der Feed ein handgehaltener Entfernungsmesser oder ein Drohnen-Telemetrie-Stream ist.

Testen und Feldvalidierung

Sensor-Plugins versagen auf Weisen, die Labortests selten aufdecken. Bluetooth-Geräte handeln Verbindungen unvorhersehbar neu aus; GPS driftet unter Baumbedeckung; die Deklination ändert sich mit dem Standort; Firmware-Revisionen ändern stillschweigend Ausgabeformate. Ein repräsentativer Validierungsdurchlauf führt das Plugin auf der tatsächlich eingesetzten robusten Android-Hardware der Einheit durch, mit dem echten Sensor, unter unzuverlässiger Konnektivität und mit dem von behandschuhten Händen erwarteten Touch-Verhalten. Erfassen Sie echte Geräteausgaben frühzeitig – Datenblätter sind unzuverlässig, und die einzige verlässliche Wahrheitsquelle für ein Ausgabeformat ist das Gerät in der Hand. Bestätigen Sie, dass Zielkoordinaten aus einer Laserentfernungsmessung dort landen, wo ein vermessener Kontrollpunkt sie verlangt, und dass das Lagebild bei Sensorausfall ordnungsgemäß, nicht täuschend, degradiert.