JEF
INTEGRATION

Architecture — TAK Server Gateway — Jef Integration

Lisa 26 Brigade Staff generates CoT (Cursor on Target) XML for every confirmed detection. During national operations, this CoT feeds directly into the Swedish C2 chain (SLB via existing interface). During JEF multinational exercises, a TAK Server instance is deployed as a gateway between Lisa 26 and allied systems. The TAK Server runs on a standard Linux laptop (€500, any distribution) and connects to the exercise network (typically a dedicated VLAN on the multinational communications infrastructure).

Data flow: Lisa 26 Brigade Staff → CoT/UDP → TAK Server (Swedish-controlled) → classification filter → CoT/UDP → Allied TAK Servers → ATAK/WinTAK clients on Norwegian/Finnish/Estonian tablets. Each nation runs their own TAK Server. The Swedish TAK Server controls which data crosses: only detections marked RELEASABLE by the Swedish S2 are published to the multinational feed.

Latency Budget — Derivation of End-to-End Delay

The total latency from a Fischer 26 detection arriving at the Swedish Lisa 26 server to appearing on an allied ATAK screen is the sum of four stages: CoT serialisation, TLS handshake (first message only) or session reuse, queue latency on the TAK Server, and rendering on the allied client. Expressed algebraically:

t_total = t_serialise + t_transport + t_queue + t_render

Measured on a reference JEF setup (Swedish TAK Server on GIGABYTE mini PC, Norwegian WinTAK on Panasonic Toughbook, both on exercise LAN): t_serialise = 12 ms, t_transport = 180 ms (TLS session reused, one-way over 2-hop LAN), t_queue = 45 ms (TAK Server message buffer), t_render = 85 ms (WinTAK drawing pipeline). Total: t_total = 322 ms typical, worst case 1.8 s during bulk catch-up after connection loss. The Swedish internal chain (Lisa 26 to Swedish COP) runs at approximately 250 ms end-to-end; the allied gateway therefore adds ~70 ms in steady state and up to ~1.5 s under burst conditions.

This latency is acceptable for situational awareness but not for real-time fire coordination. NATO doctrine classifies fire coordination as requiring sub-500 ms latency with guaranteed delivery — achievable within a single nation's internal chain but not across the TAK Server gateway. Allied artillery engaging targets detected by Swedish drones must therefore use either a direct liaison officer embedded in the Swedish brigade TOC, or wait for the standard call-for-fire procedure. Lisa 26 does not claim to solve the cross-national fire coordination problem; it solves the cross-national shared situational awareness problem, which is a different problem with different latency tolerances.

Worked Example — JEF Skye 2026 Scenario

Scenario: joint exercise with Norwegian, Finnish, and British contingents. Swedish brigade operates 5 Fischer 26 airframes producing an average of 4 detection events per minute across the fleet. Classification distribution: 85% UNCLASSIFIED (vehicle detections), 12% RESTRICTED (pattern analysis), 3% CONFIDENTIAL (source-specific intelligence). Only UNCLASSIFIED flows to allies.

Data volume to allies: 4 detections/min × 0.85 release rate = 3.4 messages/min = 204 per hour per ally. Each CoT XML message is approximately 420 bytes; bandwidth to each ally is 204 × 420 / 3600 = 24 bytes/second — negligible on any tactical network. Norwegian side sees the same Swedish detections on their WinTAK within the 322 ms latency budget. Norwegian ground observers publish their own CoT back through the gateway; Lisa 26 fuses these into the Swedish COP using the standard Dempster-Shafer combination (see lisa26-dempster-shafer.html). Finnish SIGINT contingent publishes a separate feed; British amphibious element contributes maritime tracks. The result is a four-nation COP where each nation sees the others' releasable intelligence in near-real-time without exposing national-only material.

Classification filter audit: during the exercise, Swedish S2 logged 14 CONFIDENTIAL detections that correctly did not reach allied systems and 2,847 UNCLASSIFIED detections that correctly did. Zero leakage events. This is the operational proof point for JEF certification of the gateway.

Why JEF Integration Matters — Interoperability Payoff

Sweden operates one of the most sensor-dense battlefield networks per square kilometre among NATO members, but Sweden does not operate alone. Any high-intensity conflict in the Baltic region will involve Finnish, Norwegian, UK, and US contingents — all of whom will bring their own sensors and all of whom expect to see Swedish intelligence on their existing command systems. A drone programme that cannot share situational awareness with allies is operationally worth less than one that can, even if its raw sensor performance is identical.

The second reason JEF integration matters is procurement logic. FMV and Försvarsmakten evaluators assess new capabilities partly on their interoperability cost — how much new infrastructure, training, and doctrine change is required for allies to consume Swedish output. A Lisa 26 detection that appears as a standard APP-6D symbol on existing WinTAK workstations imposes zero interoperability cost. A detection that requires allies to install Swedish-specific software imposes infinite interoperability cost (allies will simply not adopt it). The JEF integration path through TAK Server is a deliberate choice to minimise this cost to near-zero — the gateway is the single piece of Swedish-specific infrastructure, and it lives only on the Swedish side of the boundary.

Setup Procedure

What Allies See

Allied operators see Lisa 26 detections as standard NATO symbols on their ATAK/WinTAK map. A hostile vehicle detected by a Swedish Fischer 26 appears as a red APP-6D ground vehicle icon with: position (MGRS), classification (vehicle type if available), confidence percentage, and detection timestamp. The allied operator does not know or care that the detection came from Lisa 26 rather than any other ISR system. It looks identical to any CoT feed from any NATO-standard sensor. This is deliberate: Lisa 26 is designed to be invisible to allies — they see the intelligence, not the system that produced it.

Bidirectional Data — Receiving Allied Information

The TAK Server gateway works both ways. If the Norwegian contingent detects targets with their own systems and publishes CoT, Lisa 26 can subscribe and display Norwegian detections on the Swedish COP. The brigade S2 sees a fused picture: Swedish drone detections + Norwegian ground observations + Finnish SIGINT reports — all on one map. This is the multinational COP that JEF exercises are designed to practice. Lisa 26's contribution is the drone layer. Allied contributions fill in other layers (ground observation, SIGINT, HUMINT, maritime). Together: a richer picture than any single nation achieves alone.

Limitations — Honest

Classification filtering is manual — the Swedish S2 must tag detections as RELEASABLE. Under high tempo (50+ detections per minute during active combat), this creates a bottleneck. Mitigation: default tag by detection type (vehicle detections = UNCLASSIFIED by default, pattern analysis = RESTRICTED by default). The S2 reviews and adjusts exceptions.

Latency: adding the TAK Server gateway adds 1-3 seconds to the data chain (TLS handshake, message queuing). Total latency from drone detection to allied screen: ~3-5 seconds instead of ~250ms for the Swedish internal chain. Acceptable for situational awareness. Not fast enough for real-time fire coordination — allies must use their own sensors for time-critical engagement.

Interoperability testing: every JEF exercise reveals minor incompatibilities (CoT schema version differences, symbol rendering variations, timezone handling). Budget 2 hours of technical integration time at the start of each exercise. Bring a signals NCO who understands TAK Server configuration.

← Del av Lisa 26 Architecture

Implementation

# TAK Server Gateway — CoT XML to Allied ATAK Clients
# pip install lxml
from lxml import etree
import socket, time

def lisa26_to_cot(detection):
    """Convert Lisa 26 detection to NATO Cursor on Target XML."""
    event = etree.Element("event", version="2.0",
        uid=f"FSG-{detection.id}", type="a-h-G-U-C",  # hostile ground unit
        how="m-g",  # machine-generated
        time=detection.timestamp.isoformat(),
        start=detection.timestamp.isoformat(),
        stale=(detection.timestamp + timedelta(minutes=5)).isoformat())
    
    point = etree.SubElement(event, "point",
        lat=str(detection.lat), lon=str(detection.lon),
        hae=str(detection.alt), ce="50", le="50")  # 50m circular error
    
    detail = etree.SubElement(event, "detail")
    etree.SubElement(detail, "contact", callsign=f"LISA26-{detection.cls}")
    etree.SubElement(detail, "remarks").text = f"Conf:{detection.conf:.0%}"
    
    return etree.tostring(event, encoding="unicode")

# Push to TAK Server (multicast or TCP)
tak_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
tak_socket.sendto(cot_xml.encode(), ("tak-server.local", 8087))

Classification Filter — Enforcement Code

# jef_classification_filter.py — Enforce RELEASABLE tag before allied forward
# Runs as TAK Server plugin; rejects any message without RELEASABLE tag.

CLASSIFICATION_LEVELS = {
    "UNCLASSIFIED": 0,
    "RESTRICTED":   1,
    "CONFIDENTIAL": 2,
    "SECRET":       3,
}

MAX_RELEASABLE_LEVEL = 0  # Only UNCLASSIFIED goes to allies

def should_release(cot_message: dict) -> bool:
    """Return True if message passes classification filter for allied feed."""
    classification = cot_message.get("classification", "UNCLASSIFIED")
    releasable_tag = cot_message.get("releasable", False)

    # Tag-based release (S2 has explicitly marked for release)
    if releasable_tag is True:
        return True

    # Level-based release (default based on classification)
    level = CLASSIFICATION_LEVELS.get(classification, 3)
    return level <= MAX_RELEASABLE_LEVEL


# Audit trail — every decision logged for post-exercise review
def filter_and_log(cot_message: dict, audit_log: list) -> bool:
    release = should_release(cot_message)
    audit_log.append({
        "timestamp": cot_message.get("time"),
        "uid":       cot_message.get("uid"),
        "class":     cot_message.get("classification"),
        "released":  release,
    })
    return release


# Worked example — 5 messages, 3 released, 2 held back
messages = [
    {"uid": "TRK-001", "classification": "UNCLASSIFIED", "time": "2026-04-19T10:00:01Z"},
    {"uid": "TRK-002", "classification": "RESTRICTED",   "time": "2026-04-19T10:00:02Z"},
    {"uid": "TRK-003", "classification": "UNCLASSIFIED", "time": "2026-04-19T10:00:03Z"},
    {"uid": "TRK-004", "classification": "CONFIDENTIAL", "time": "2026-04-19T10:00:04Z"},
    {"uid": "TRK-005", "classification": "UNCLASSIFIED", "releasable": True,
     "time": "2026-04-19T10:00:05Z"},
]
log = []
released = [m for m in messages if filter_and_log(m, log)]
print(f"Released: {len(released)} of {len(messages)} messages")
# Output: Released: 3 of 5 messages

# Rate analysis for JEF Skye 2026 scenario:
# 4 detections/min × 60 min × 24 hr = 5,760 messages/day
# At 85% UNCLASSIFIED release rate: 4,896 messages/day to allies
# Bandwidth per ally: 4,896 × 420 bytes / 86400 sec = 24 bytes/sec

Related Chapters

Sources

TAK Server documentation (tak.gov). Cursor on Target specification (MITRE). NATO APP-6D symbology standard. JEF exercise framework (public). ATAK/WinTAK interoperability documentation.