Das TAK-Protokoll ist der Übertragungsvertrag, mit dem ATAK, WinTAK, iTAK und TAK Server Cursor-on-Target-Ereignisse (CoT) austauschen. Version 0 verschickt das Ereignis als schlichtes XML; Version 1 als protobuf-Nachricht mit Längenpräfix, etwa halb so groß. Dieselbe Nutzlast reist über drei Transporte: serverloses UDP-Multicast im lokalen Mesh, dauerhafte TCP/TLS-Streams zum TAK Server (standardmäßig Port 8089) und Server-zu-Server-Föderation (9000/9001).

Wer ein Sensor-, Drohnen- oder C2-System in das TAK-Ökosystem integriert, spürt diese Unterscheidung sofort: CoT ist das Datenmodell — <event>, <point>, <detail> — während das TAK-Protokoll festlegt, wie diese Bytes auf jedem Transport gerahmt, versioniert und ausgehandelt werden. Das XML-Schema selbst behandelt unser Leitfaden zum Cursor-on-Target-Format und der tiefe Blick in das CoT-Schema; dieser Artikel ist die andere Hälfte: die Leitung.

CoT vs. TAK-Protokoll: Datenmodell vs. Übertragungsvertrag

Halten Sie drei Schichten auseinander — die Ökosystem-Dokumentation vermischt sie regelmäßig:

  • Das CoT-Ereignismodell. Ein XML-Dokument pro Ereignis: Typcode, UID, time/start/stale, ein WGS-84-Punkt, ein erweiterbares <detail>. Der semantische Inhalt, auf jedem Transport identisch.
  • Die Kodierung (TAK-Protokollversion). Version 0 kodiert das Ereignis als XML-Text; Version 1 als protobuf-TakMessage. Beide tragen dieselben Ereignisse.
  • Der Transport. UDP-Multicast im Mesh, ein dauerhafter TLS-Stream zum TAK Server oder eine Föderationsverbindung zwischen Servern — jeder rahmt die Nutzlast anders.

Die mit den TAK-Produkten vertriebene Protokollbeschreibung setzt zwei Grundregeln: Ein Client, der Version V sendet, kann Version V auch dekodieren, und jeder Client muss weiterhin XML der Version 0 dekodieren. Deshalb funktionieren gemischte Flotten weiter — alles fällt graceful auf XML zurück.

Diagramm der TAK-Protokoll-Transporte: ATAK-, WinTAK- und iTAK-Geräte teilen sich serverloses UDP-Multicast auf 239.2.3.1:6969; Geräte oder ein CoT-Gateway streamen zum TAK Server über Mutual TLS auf Port 8089; der Server föderiert mit einem zweiten TAK Server auf den Ports 9000 und 9001; Sensor- und C2-Feeds wandelt der Gateway-Dienst zu CoT.
TAK-Protokoll-Transporte: serverloses Mesh-Multicast, Mutual-TLS-Streaming zum TAK Server (8089) und Server-zu-Server-Föderation (9000/9001), mit einem CoT-Gateway als Quelle.

TAK-Protokoll Version 0: schlichtes CoT XML

Version 0 hat das Ökosystem das erste Jahrzehnt getragen und ist bis überall der Fallback. Auf jedem Transport verhält sie sich anders:

  • Mesh SA (Multicast). Lagemeldungen sind UDP-Datagramme an die wohlbekannte Multicast-Gruppe 239.2.3.1:6969 — ein CoT-XML-Ereignis pro Datagramm, ganz ohne Server. Jedes Gerät in der Gruppe empfängt jedes Ereignis, eine Wiederholung gibt es nicht: ein verlorenes Datagramm ist ein verlorener Positionsmeldung. Das ist der Modus hinter serverlosem Blue Force Tracking in einem Zug-Wi-Fi- oder MANET-Segment. (ATAK multicastet GeoChat auf einer separaten Gruppe, 224.10.10.1:17012, die der TAK Server als Eingang einbinden kann.)
  • Gerichtete Nachrichten. Nachrichten an einen Empfänger laufen über eine kurzlebige TCP-Verbindung: verbinden, ein Ereignis senden, trennen. Ein ATAK-Gerät, das auf direkte Peers lauscht, nimmt sie auf TCP-Port 4242 an — praktisch, um einem einzelnen Endgerät ohne Server ein Ereignis zu injizieren.
  • Stream zum TAK Server. Eine dauerhafte Verbindung (meist TLS) trägt einen End-to-End-Strom von XML-Ereignissen, jedem eine XML-Deklaration vorangestellt und ein Zeilenumbruch nachgestellt. Der Empfänger bekommt kein Längenpräfix und kein Trennzeichen: Er zerschneidet den Strom, indem er nach dem Literal-Token </event> sucht und unmittelbar dahinter schneidet — die nächste Deklaration beginnt im aller nächsten Byte.

In der Praxis sieht die Streaming-Form so aus (gekürzt):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<event version="2.0" uid="RAVEN-1" type="a-f-G-U-C" how="m-g" …>…</event><?xml version="1.0" …?><event …>…</event>

Dieser Token-scannende Splitter ist Protokollverhalten, keine Implementierungseigenheit — der eigene Streaming-Codec des TAK Servers dokumentiert das Fehlen von Trennzeichen ausdrücklich und sucht das schließende Tag. Jedes Gateway muss Ereignisse ausgeben, die sauber schneiden: vollständige Ereignisse, Deklaration zuerst, nichts dazwischen. Annotierte vollständige Ereignisse stehen in unseren CoT-Nachrichtenispielen.

TAK-Protokoll Version 1: die protobuf-TakMessage

Version 1 ersetzt den XML-Text durch eine einzige proto3-Nachricht — atakmap.commoncommo.protobuf.v1.TakMessage —, deren Definition mit den TAK-Distributionen ausgeliefert und in Bibliotheken wie dem Python-Paket takproto gespiegelt wird. Die Struktur ist kompakt, aber streng festgelegt:

  • TakMessage hält zwei optionale Teile: ein TakControl (Protokoll-Buchhaltung — die vom Sender dekodierten Min-/Max-Versionen plus eine Kontakt-UID) und das CotEvent selbst.
  • CotEvent trägt den Umschlag: type, uid, how, optionale access/qos/opex, die drei Zeitstempel als Millisekunden seit der Unix-Epoche (sendTime, startTime, staleTime) sowie die Punktfelder lat, lon, hae, ce, le als doubles. Unbekannte Höhe oder Fehlerwerte nutzen den Sentinel 999999, wie in der XML-Konvention.
  • Detail wird jetzt interessant. Sechs wohlbekannte Detail-Elemente wurden zu typisierten Unternachrichten: contact (endpoint, callsign), group (aus __group: name, role), precisionLocation (geopointsrc, altsrc), status (battery), takv (device, platform, os, version), track (speed, course). Alles andere — remarks, Chat-Inhalte, Plugin-Elemente — wird in einen einzigen xmlDetail-String mit dem rohen XML der restlichen Kinder gestopft.

Zwei Spezifikationsregeln retten Teams vor schleichender Datenkorruption. Erstens, nur ganze Elemente: Ein Detail-Element wird vollständig in seine typisierte Nachricht umgewandelt oder verbleibt vollständig im xmlDetail — nie geteilt, und wenn es sich nicht sauber mappen lässt, bleibt es im xmlDetail. Zweitens fügen Empfänger die typisierten Nachrichten wieder zu XML zusammen, und bei Konflikten gewinnt xmlDetail. Neue Felder dürfen nur hinten an bestehende Nachrichten angehängt werden; alles Semantische verlangt eine neue Version. Praktisch schrumpft der protobuf-Vorteil, sobald untypisiertes Detail wächst — genau das zeigt sich bei chat- oder plugin-lastigem Verkehr.

Mesh- und Stream-Framing: die konkreten Bytes

Beide Versionen fahren auf beiden Transporten; das Framing unterscheidet sich nach Transport, nicht nach Nutzlast:

  • Mesh-Datagramm: 0xbf, ein Varint der Protokollversion, 0xbf, dann die Nutzlast. Das Magic Byte 0xbf (191 dezimal) lässt einen Empfänger ein einziges Datagramm erschnüffeln und wissen, ob es protobuf ist oder Legacy-XML, das mit < beginnt — die UDP-Eingänge des TAK Servers machen exakt diese Prüfung bei jedem Datagramm.
  • Streaming-Frame: 0xbf, ein Varint der Nutzlänge in Bytes, dann die Nutzlast. Kein Versionsbyte — die Version wurde einmal pro Verbindung ausgehandelt (nächster Abschnitt), sie pro Frame zu wiederholen wäre Verschwendung.

Die Varints sind standardmäßige vorzeichenlose protobuf-Varints — 7 Bits auf einmal, niederwertig zuerst, das höchste Bit markiert die Fortsetzung, maximal 64 Bits (10 Bytes). Eine 258-Byte-Nutzlast kodiert als 82 02; 127 ist 7f, 128 ist 80 01.

Byte-Layout-Diagramm zum TAK-Protokoll-Framing: ein UDP-Mesh-Datagramm als 0xbf, Versions-Varint, 0xbf, dann die protobuf-TakMessage-Nutzlast; ein Streaming-Frame über TCP oder TLS als 0xbf gefolgt von einem Längen-Varint und der Nutzlast; und Version-0-XML-Ereignisse, die am schließenden Event-Token geschnitten werden.
TAK-Protokoll v1 Framing: Der Mesh-Header wiederholt Magic Byte, Version, Magic Byte; der Stream-Header ist Magic Byte plus Längen-Varint; Version 0 trägt rohes XML, geschnitten am schließenden Event-Token.

Weil jeder Frame seine eigene Länge trägt, ist ein Stream-Parser eine winzige Zustandsmaschine: 0xbf erwarten, das Varint aufsammeln, exakt so viele Bytes puffern, dekodieren, wiederholen — unvollständige Frames über Lesevorgänge hinwegtragen. Version 0 bietet nichts davon; Sie scannen Text nach </event> und hoffen, dass mitten im Ereignis nichts abbricht.

Streaming-Aushandlung: t-x-takp-v, t-x-takp-q, t-x-takp-r

Ein Client kann nicht wissen, ob ein Server protobuf spricht, deshalb wird die Umschaltung innerhalb der Verbindung mit drei CoT-Steuerereignissen ausgehandelt — selbst als XML gesendet:

  1. Das Angebot (t-x-takp-v). Ein Server mit TAK-Protokollunterstützung darf ein Ereignis dieses Typs mit <detail><TakControl><TakProtocolSupport version="1"/> senden — ein Element pro unterstützter Version, höchstens einmal pro Verbindung, nach der Authentifizierung, wenn der Eingang sie verlangt.
  2. Die Anfrage (t-x-takp-q). Der Client wählt eine Version aus dem Angebot und antwortet mit <TakRequest version="1"/>; danach muss er aufhören, XML zu senden (eingehendes XML weiterverarbeiten), und warten — mindestens eine Minute, bevor er aufgibt und neu verbindet.
  3. Die Antwort (t-x-takp-r). Der Server antwortet <TakResponse status="true"/> oder "false". Bei true stellen beide Seiten die gesamte Verbindung auf längengerahmte Nutzlasten der Version 1 um — dieselbe Version in beide Richtungen — und es fließt kein XML mehr. Bei false bleibt die Verbindung auf XML, und der Client kann es später erneut versuchen.

Alle drei Ereignisse teilen eine Transaktions-UID (die protouid der Spezifikation), und der Tanz ist streng: protobuf vor der true-Antwort bricht an dem Referenzserver. Im Mesh gibt es keinen Handshake: Jedes Gerät sendet mindestens alle 60 Sekunden eine TakControl-Nachricht und deklariert die minimale und maximale Version, die es dekodiert; Kontakte, die zwei Minuten schweigen, fallen auf die Version ihrer letzten dekodierbaren Nachricht zurück; und alle senden auf der höchsten Version, die alle bekannten Kontakte dekodieren können, mit Rückfall auf XML, sobald ein Legacy-Gerät dabei ist. Belasten Sie die Aushandlung mit Tests, bevor Sie eine umgestellte Flotte annehmen — die Tuning-Hebel beschreibt unser Leitfaden zur TAK-Server-Performance.

TAK-Server-Ports: die Standard-Landkarte

Vorgabewerte aus dem Konfigurationsleitfaden für TAK Server 5.7 und seiner Beispiel-CoreConfig.xml; jeder Port ist konfigurierbar, betrachten Sie das also als das, was eine Auslieferungs-Installation öffnet, nicht als Vertrag. Die eigene Firewall-Empfehlung des Leitfadens ist minimal: 8089 und 8443 öffnen.

PortProtokollRolle
8089TCP/TLSCoT-Streaming-Eingang — hierhin verbinden sich ATAK, WinTAK und Gateways mit Client-Zertifikaten
8090UDP (QUIC)Optioneller QUIC-Streaming-Eingang, in der aktuellen Beispielkonfiguration vorhanden
8087TCP oder UDPUnverschlüsselter CoT-Eingang (Beispiel-Eingänge; nur fürs Labor)
8088TCPStreaming-TCP ohne TLS (stcp) — nur zum Testen
8443TCP/HTTPSAdmin-UI, REST-API und WebTAK (Client-Zertifikats-Authentifizierung)
8444TCP/HTTPSFöderationsseitiges HTTPS (Föderations-Truststore; Mission-Package-Abruf)
8446TCP/HTTPSZertifikatsregistrierung (CSR, HTTP Basic Auth) und OAuth2-Token-Endpunkt
9000TCP/TLSFederation-v1-Listener
9001TCP/TLSFederation-v2-Listener (gRPC über HTTP/2)
9002TCP/TLSFöderations-Token-Authentifizierung (falls aktiviert)
239.2.3.1:6969UDP-MulticastMesh-SA-Gruppe (Client-Vorgabe; als Server-Eingang einbindbar)

Zwei Fußnoten. FreeTAKServer, der Python-Server des Open-Source-Ökosystems (siehe unseren Leitfaden zum Open-Source-TAK-Ökosystem), behält 8089 für CoT über TLS, nutzt aber 8087 für unverschlüsseltes TCP-CoT. Und die Föderation verdient eine eigene Lektüre: Die v1-Verbindung tauscht protobuf-FederatedEvent-Nachrichten hinter einem Vier-Byte-Längenpräfix aus, während v2 einen gRPC-Dienst mit Streaming-RPCs und Health Checks fährt — behandelt in unserem Leitfaden zum Föderations-Setup und der Architekturübersicht des Federation Hub.

Nachrichtengröße und Bandbreite: XML vs. protobuf

Wir haben zwei repräsentative Ereignisse auf beide Arten kodiert — einen ATAK-artigen Eigenpositionsmeldung (typisiertes Detail plus ein untypisiertes uid-Element) und einen kleinen Drohnen-Track einer MAVLink-Bridge, die protobuf-Seite mit dem Referenz-Python-Encoder:

EreignisCoT XMLXML im Stream (mit Deklaration)Protobuf-NutzlastAuf der Leitung (gerahmt)
ATAK-Eigenpositionsmeldung578 B634 B258 B261 B
UAV-Bridge-Track363 B419 B171 B174 B

Das sind 52–59 % Ersparnis für diese Formen — im Einklang mit den 55–65 %, die wir in unserem Artikel zur Drohnen-Telemetrie-Integration nannten, und mit Isodes Feldmessungen von 2025 für TAK über Kurzwelle: rund 530-Byte-XML-Ereignisse gegen 376–380-Byte föderierte protobuf-Nachrichten, vor Kompression. Protobuf hilft am meisten dort, wo XML reiner Umschlag ist — Deklarationen, Attributnamen, schließende Tags —, während im xmlDetail geparktes Detail seine XML-Größe behält.

Warum das im Funknetz zählt: Vierzig Nutzer, die sich alle zehn Sekunden selbst melden, kosten rund 20 kbps an gestreamtem XML (je 634 B) gegen rund 8 kbps an protobuf — vor dem TLS-Record-Overhead pro Nachricht. Auf Schmalband fällt die Wirkung brutal aus — bei 75 bps maß Isode 29–33 Sekunden Ende-zu-Ende-Latenz für ein einzelnes Ereignis. Noch ein Größenverhalten: Der Streaming-Ausgang des TAK Servers weigert sich, eine protobuf-TakMessage größer als 65.536 Bytes zu senden; ein übergroßes Ereignis wird durch einen kleinen Dateiübertragungs-Zeiger ersetzt, der den Client anweist, das volle XML per HTTPS zu holen. Chat-Verkehr wird in unserem Artikel zur Datenstrategie für taktischen Chat untersucht.

CoT aus Python senden: TLS, Zertifikate, protobuf

Alles oben verdichtet sich zu einem kleinen Programm — allein die Standardbibliothek kann eine TLS-Verbindung zum 8089-Eingang mit Client-Zertifikat öffnen und XML-Ereignisse der Version 0 streamen, ohne Abhängigkeiten:

import asyncio
import datetime as dt
import ssl
import xml.etree.ElementTree as ET

TAK_HOST, TAK_PORT = "tak.example.org", 8089      # TLS streaming input
CA_FILE, CERT_FILE, KEY_FILE = "takserver-ca.pem", "client.pem", "client.key"

def ts(t):  # CoT time: ISO 8601, UTC, millisecond precision
    return t.strftime("%Y-%m-%dT%H:%M:%S.") + f"{t.microsecond // 1000:03d}Z"

def cot_event(uid, cot_type, lat, lon, hae, callsign, stale_s=60):
    now = dt.datetime.now(dt.timezone.utc)
    ev = ET.Element("event", version="2.0", uid=uid, type=cot_type, how="m-g",
                    time=ts(now), start=ts(now),
                    stale=ts(now + dt.timedelta(seconds=stale_s)))
    ET.SubElement(ev, "point", lat=f"{lat:.7f}", lon=f"{lon:.7f}",
                  hae=f"{hae:.1f}", ce="10.0", le="9999999.0")
    ET.SubElement(ET.SubElement(ev, "detail"), "contact", callsign=callsign)
    return ET.tostring(ev, encoding="utf-8", xml_declaration=False)

async def drain(reader):
    # Keep reading the server (its t-x-takp-v offer, other users' SA),
    # or TCP flow control eventually stalls its writes to you.
    while await reader.read(65536):
        pass

async def main():
    ctx = ssl.create_default_context(cafile=CA_FILE)   # verify server cert + name
    ctx.load_cert_chain(CERT_FILE, KEY_FILE)           # our client identity
    reader, writer = await asyncio.open_connection(TAK_HOST, TAK_PORT, ssl=ctx)
    rx = asyncio.create_task(drain(reader))
    try:
        while not rx.done():
            writer.write(cot_event("gw-demo.uav-12", "a-f-A-M-F-Q",
                                   50.4501234, 30.5234567, 640.0, "UAV-12"))
            await writer.drain()
            await asyncio.sleep(5)                     # report well inside stale
    finally:
        writer.close()

asyncio.run(main())

Drei Details tragen hier die Last. Asyncio-Sockets deaktivieren Nagles Algorithmus standardmäßig, sodass jedes Ereignis sofort rausgeht — bei rohen Sockets setzen Sie TCP_NODELAY selbst. Die drain-Aufgabe ist keine Zierde: Ein Server, der auf einen Client schreibt, der nie liest, bleibt irgendwann an der TCP-Flusskontrolle hängen. Zertifikate müssen PEM sein: Der TAK Server stellt ein PKCS#12-.p12 aus (was ATAK konsumiert), das OpenSSL in drei Zeilen wandelt:

openssl pkcs12 -in gateway-01.p12 -clcerts -nokeys -out client.pem -passin pass:SECRET
openssl pkcs12 -in gateway-01.p12 -nocerts -nodes -out client.key -passin pass:SECRET
openssl pkcs12 -in truststore-root.p12 -nokeys -out takserver-ca.pem -passin pass:SECRET

Für protobuf wandelt das Paket takproto (PyPI) CoT-XML in Version-1-Nutzlasten und zurück und ergänzt das Framing; die Bibliothek PyTAK hüllt den ganzen Client ein — COT_URL akzeptiert tls://host:8089 oder udp+wo://239.2.3.1:6969, TAK_PROTO=1 wählt protobuf, und Zertifikate importieren sich direkt aus einem TAK-Datenpaket .zip. Die Rechnung „selbst bauen oder Bibliothek übernehmen" führt unser Artikel zu den TAK-C2-Integrationsmustern aus.

Hier trifft der Wochenend-Prototyp auf operative Realität: Zertifikatsregistrierung im Flottenmaßstab, protobuf-Aushandlung über gemischte Client-Versionen, Multicast, das tatsächlich geroutet werden muss. Wir bauen CoT/TAK-Protokoll-Gateways, migrieren Feeds von XML zu protobuf und integrieren und härten TAK Server. Sagen Sie uns, was Sie anbinden müssen →

Zustellsemantik, Sicherheit und die Fallstricke, die beißen

Keine Bestätigungen — die stale-Zeit übernimmt die Arbeit

CoT ist auf jeder Ebene Fire-and-Forget: keine Bestätigungen pro Nachricht, keine Sequenznummern, keine Sitzungen. Frische wird über den stale-Zeitstempel verwaltet — Konsumenten lassen Ereignisse darüber altern oder verwerfen sie — und über den Takt: Senden Sie klar innerhalb Ihres stale-Fensters oder akzeptieren Sie Geister auf der Karte. Der TAK Server mildert Wiederverbindungen mit seinem latest SA-Puffer ab (neue Clients erhalten sofort die letzten bekannten Positionen erreichbarer Nutzer), und ATAK hält Verbindungen mit einem Ping (t-x-c-t) am Leben, den der Server mit einem Pong (t-x-c-t-r) beantwortet. Senden Sie Ihr aktuelles Bild nach jedem Reconnect neu, statt anzunehmen, der Server habe es behalten.

Zertifikate, Gruppen, Kanäle

Operativer TAK-Verkehr ist Mutual TLS: Der Client verifiziert den Server gegen die CA der Installation, der Server ein Client-Zertifikat derselben CA, und der CN des Zertifikats wird zum Benutzernamen für die Gruppenzuweisung. Gruppenmitgliedschaft — pro Eingang, pro Zertifikat oder über LDAP-/Datei-Backends — ist das gesamte Zugriffsmodell dafür, wessen Spuren wer sieht; nicht zuordbare Verbindungen landen in __ANON__. Die Föderation nutzt bewusst einen separaten Truststore, sodass eine Partner-CA nie stillschweigend Client-Verbindungen autorisiert, und die Registrierung läuft auf Port 8446 hinter HTTP Basic Auth. Wo eine Installation HTTP-APIs statt roher Sockets braucht, beschreibt unser Leitfaden zur CloudTAK-API-Integration diese Fläche.

Die wiederkehrenden Fehlerbilder

  • Multicast, das nicht ankommt: Multicast wird nur weitergereicht, solange das TTL es erlaubt (Standard-TTL 1 hält Datagramme im lokalen Segment; die Beispielkonfiguration des TAK Servers hebt es auf 5), falsch konfiguriertes IGMP Snooping verwirft Gruppen lautlos, und Multicast durchquert nie NAT. Mesh SA ist Same-Subnet-Technik.
  • Uhrenabweichung: Bei stale-basierter Alterung lässt eine falsche Uhr entweder jedermanns Spuren verdampfen oder ewig liegen. Synchronisieren Sie die Zeit (GNSS oder NTP), bevor Sie irgendetwas anderes debuggen.
  • Zertifikatsformat-Reibung: Der Server spricht JKS, die Clients PKCS#12, Ihr Dienst PEM — und Zertifikate ohne die Extended-Key-Usage client-auth werden schon im Handshake abgelehnt. Konvertieren Sie bewusst und testen Sie die exakte Kette.
  • Nagles Algorithmus: Eine 200-ms-Batching-Verzögerung ist im Rechenzentrums-Link unsichtbar und im taktischen Link tödlich. Schalten Sie ihn ab oder batchen Sie explizit.
  • Reconnect-Stürme: Hundert Gateways, die nach einem Funkausfall gleichzeitig wiederverbinden, wirken wie ein DDoS. Nutzen Sie Jitter und exponentielles Backoff, authentifizieren Sie sich neu, spielen Sie den aktuellen Zustand ein.
  • Annahmen über gemischte Versionen: Ein einziger Legacy-Client im Mesh wirft alle zurück auf XML, und ein Server, der nie t-x-takp-v anbietet, bekommt nie protobuf. Instrumentieren Sie, auf welche Kodierung Ihre Links sich eingelassen haben — Bytes auf der Leitung pro Minute sagen die Wahrheit.

Referenzarchitektur: ein CoT-Gateway-Dienst

Das tragfähige Muster, ein TAK-Netz aus Nicht-TAK-Systemen zu speisen, ist ein kleiner, dedizierter Gateway-Dienst — kein Code, der in jede Quelle eingebettet ist:

  • Eingangs-Adapter — MAVLink, Radar, AIS, GPS-Tracker, REST-/WebSocket-Feeds — jeder auf ein internes Track-Modell normalisiert.
  • Ein CoT-Builder — eine Stelle, die die UID-Politik besitzt (stabil, namensraumiert, kollisionsfest), Typ-Mapping, how-Codes und stale-Fenster pro Quelle, und XML oder protobuf nach denselben Detail-Regeln emittiert.
  • Ein Ausgangs-Aufseher — ein Pool authentifizierter TLS-Verbindungen mit Aushandlung (protobuf, wenn angeboten, sonst XML), Jitter-Reconnects, Ratenformung pro Link für Schmalbandpfade und Replay des aktuellen Zustands.
  • Betriebsfläche — Link-Gesundheit, aktive Kodierung, Bytes pro Minute und Monitoring des Zertifikatsablaufs; in taktischen Netzen ist das Protokoll der erste Verdächtige und das letzte Instrumentierte.

Diese Form — ein protokollgetreuer Rand zwischen den Daten anderer und einem TAK Server — ist eine Komponente, die wir für Verteidigungsprogramme bauen, Seite an Seite mit dem TAKpilot-Copiloten auf derselben Infrastruktur. Wenn Ihr Programm dieses Diagramm gerade zeichnet, holen Sie ein Team, das es bereits ausgeliefert hat.

Das brauchen Sie in Ihrem Netz?

Wir bauen CoT/TAK-Protokoll-Gateways, migrieren Feeds von XML zu protobuf und integrieren und härten TAK Server — inklusive Zertifikaten, Gruppen und Föderation.

Bauen Sie Ihr CoT-Gateway → TAKpilot ansehen →

Erstellt vom Engineering-Team von Corvus Intelligence, das CoT/TAK-Gateways, ATAK-Plugins und TAK-Server-Integrationen für Verteidigungsprogramme baut (ISO 9001/27001-zertifiziert, Brave1-Mitglied). Über Corvus Intelligence →