Part 1 settled the conformance envelope. Part 2 implements the tactical data links that anchor most NATO-interoperable platforms: Link 16 for air and air-defense operations, Cursor on Target for the tactical edge, MIP4-IES for ground-force C2 exchange, and STANAG 4559 for ISR product exchange. Each has its own engineering pattern, its own conformance discipline, and its own failure modes. Part 2 walks through them.

The architectural framing is in The Complete Guide to NATO Interoperability. The companion C2 fusion-engine series at Building a Defense Fusion Pipeline covers the adapter layer that consumes these data links inside the platform.

Link 16 is the canonical NATO tactical data link for air and air-defense. It is also the most-misunderstood standard by software engineers entering defense. The protocol is time-slotted (Time Division Multiple Access), the message catalogue (J-series messages) is classified, the participation rules are bandwidth-managed, and the integration is almost always through a hardware MIDS terminal rather than a software radio.

The pragmatic implementation pattern for software:

Integrate through the MIDS terminal API. The hardware terminal handles the time-slotted protocol; the software handles the message marshalling above it. The terminal exposes a vendor-supplied API — SIMPLE (Standard Interface for Multiple Platform Link Evaluation) is the most common — through which the software submits J-series messages for transmission and receives incoming J-series for processing.

Treat the SIMPLE interface as a stable contract. The interface evolves slowly; the message catalogue evolves faster. Version the integration around the message catalogue editions, not the SIMPLE version. Catalogue updates are scheduled events with their own conformance retesting.

Marshall messages with strict typing. J-series messages have rigid structures defined in the classified catalogue. Implement them as code-generated types (where the catalogue access permits) or as hand-written types with extensive validation. Loose typing in Link 16 marshalling is the root cause of most CWIX conformance failures.

Buffer outbound, validate inbound. Outbound messages are queued by priority; the platform must not flood the terminal. Inbound messages are validated against the catalogue before propagating; malformed J-series are rejected with structured logging, not silently passed through.

The deeper engineering view, including the integration topology and the most common pitfalls, is in Link 16 Tactical Data Links: Engineering View.

Step 2: Cursor on Target Integration

CoT is the de-facto tactical lingua franca outside formal NATO catalogues. Originated in the U.S. Air Force, adopted across the ATAK/WinTAK ecosystem, increasingly required in coalition operations regardless of formal NATO standing. A NATO-interoperable platform operating alongside U.S. or ATAK-equipped allied forces will encounter CoT whether or not the formal conformance envelope includes it.

CoT is technically simpler than Link 16 — XML-based, well-defined schema, no classified message catalogue, no time-slotted protocol. The engineering rigour required is the same.

The implementation pattern:

Schema validation at the boundary. Every incoming CoT message is validated against the schema before further processing. Malformed messages are logged loudly and rejected; silent acceptance is the wrong default.

Strict timestamp handling. CoT messages carry observation time, message-stale time, and stale time. The three-timestamp discipline from earlier engineering walkthroughs applies — observation time drives correlation, stale time drives lifecycle decisions, conflating them is a recurring bug source.

Conservative parsing of optional fields. CoT extensions are common; not all extensions are documented. Parse what is documented; ignore what is not (with logging); never crash on unexpected content.

Transport flexibility. CoT moves over multicast UDP, TCP point-to-point, TCP-via-TAK-Server, and (increasingly) MQTT. The adapter layer accommodates all four with a common processing path downstream.

The detailed CoT engineering treatment is in Cursor on Target (CoT): The XML Standard Behind Tactical Awareness Apps. The ATAK plugin development perspective is in ATAK Plugin Development.

Step 3: MIP4-IES Implementation

For exchange with national C2 systems above brigade level, MIP4-IES is the schema. It is dense, version-controlled, and unforgiving in conformance testing. The Multilateral Interoperability Programme defines the model; the Information Exchange Specification serializes it.

The engineering pattern that succeeds:

Treat MIP4 as a strict interface, not an internal model. The platform's internal data model is whatever the engineering team designs; MIP4 is the wire format the platform speaks at the coalition boundary. Mapping between them is bidirectional and lossless for operationally significant fields.

Round-trip preservation is the test. A MIP4 message marshalled out of the platform, then unmarshalled back in, must produce the same internal model (modulo intentional canonicalization). Round-trip failures surface lossy mappings, type-coercion bugs, and field-aliasing errors.

Schema-driven code generation. The MIP4-IES schema is large enough that hand-written marshalling code drifts. Generate the types from the published schema; maintain mapping code separately and review it explicitly.

Version pinning with explicit transitions. MIP4 editions change. The platform pins to a specific edition for its current operational deployment; transitions are scheduled projects with conformance retesting.

The deep engineering view of MIP4-IES, including the data-model anatomy and the conformance-testing reality, is in MIP4-IES: The NATO Ground Standard.

Step 4: STANAG 4559 ISR Exchange

STANAG 4559 (NSILI — NATO Standard ISR Library Interface) governs ISR imagery and product exchange across coalition C2 platforms. Required for any platform that consumes or produces national-source imagery in a coalition context.

The implementation reality:

Consumer-side first. Most defense software programmes are NSILI consumers — they query coalition imagery libraries and integrate the results — rather than NSILI providers. The consumer-side interface is well-defined and tractable; provider-side implementation is a heavier programme with additional accreditation overhead.

Bandwidth-aware retrieval. ISR imagery is large. Retrieval over tactical links must be bandwidth-conscious — preview thumbnails first, full resolution on operator request, progressive download for the largest products. The platform's UI surfaces the bandwidth state so operators understand the trade-off.

Imagery store separation. Retrieved imagery lives in a dedicated object store, not the operational track database. Metadata maps imagery to track context; the imagery itself is referenced, not embedded.

Classification labelling on imagery. Retrieved imagery carries source classification per STANAG 4774/4778. The classification follows the imagery through the platform — display layer, audit trail, downstream analytics. Stripping the binding "for convenience" is the kind of shortcut accreditation reviewers specifically look for; Part 3 of this series covers the discipline in detail.

The deeper STANAG 4559 implementation pattern is in STANAG 4559 Implementation: NSILI in Practice.

Step 5: ADatP-34 Profile Binding

The individual data links — Link 16, CoT, MIP4, STANAG 4559 — implement specific standards. ADatP-34 profile alignment requires that the platform implement the right combinations of these standards and that the combinations satisfy the profile's interoperability scenarios.

The discipline of profile binding:

Profile-driven test scenarios. For each ADatP-34 profile the platform targets, the conformance test suite includes scenarios that exercise the data links in combination. A scenario might require: receive a Link 16 air-track update, correlate with a CoT ground-track from ATAK, query NSILI for area imagery, fuse all three into a single COP display. The scenario tests the combination, not the individual standards.

Profile-driven message catalogues. The profile defines which J-series messages are required, which MIP4 message types must be exchanged, which CoT extensions are expected. The platform implements the required subset, not the entire catalogue.

Profile evolution tracking. ADatP-34 profiles evolve. The platform tracks the current operational profile and the next-spiral profile. Engineering work that targets the current profile but anticipates the next is the discipline that survives version transitions.

Key insight: Conformance is profile-shaped, not standard-shaped. A platform that implements every required standard but fails to integrate them per the profile's scenarios will fail conformance testing. Build the implementation against the profile from sprint one, not against the standards in isolation.

Step 6: Bilateral and Non-NATO Bridges

The platforms that operate in real coalition deployments need bridges beyond the NATO catalogue. Ukrainian Delta integration, FVEY-only protocols, partner-specific extensions — each is a bridge sitting alongside the formal NATO data links.

The Delta-format engineering pattern is in Delta Format and Ukrainian Military Integration. The broader coalition-sharing patterns, including the policy considerations, are in Coalition Data Sharing Challenges.

The architectural rule: bilateral bridges are separate adapters, not modifications to the NATO data-link code. A bridge to Delta does not touch the Link 16 marshalling; a bridge to a U.S. national protocol does not touch the CoT processing. Adapter isolation extends across protocols, not just sensor types.

Step 7: Build the Conformance Harness Early

Conformance testing is the work that distinguishes platforms that pass CWIX from platforms that fail. The harness that runs these tests is engineering infrastructure as significant as the platform itself.

The harness components:

  • Per-standard test suites. Link 16 J-series message round-trip; CoT well-formedness and semantic correctness; MIP4 entity exchange and round-trip; STANAG 4559 query, retrieval, and metadata mapping. Each suite is automated, gated in CI, and produces structured reports.
  • Captured-data replay. Captured wire traffic from real exercises and operational deployments replayed against the platform. Ground truth for regression testing.
  • Partner-system simulators. Where real partner systems are not available for unit testing, simulators stand in. They exchange compliant messages with the platform and verify the responses match the standard.
  • Scenario-based integration tests. ADatP-34 profile scenarios exercised end-to-end. The platform receives inputs, performs fusion, produces outputs that the test harness validates against expected ground truth.
  • CWIX-prep tracking. Test cases that the platform plans to submit at CWIX are tracked separately, with pass-fail status visible to programme leadership well before the exercise.

The cost of building this discipline early is real but bounded; the cost of skipping it surfaces as multi-month delays during the actual conformance period. Programmes that ship NATO-interoperable platforms on schedule are programmes that built the conformance harness in year one.

What's Next

Part 2 has implemented the tactical data links. Link 16 through the MIDS terminal, CoT through the schema-validating adapter, MIP4-IES through the round-trip-preserving mapping, STANAG 4559 through the consumer-side query interface, all bound together by the ADatP-34 profile and exercised by the conformance harness.

Part 3 covers the classification and releasability machinery — STANAG 4774/4778 binding, policy engine implementation, cross-enclave data flows, and the coalition releasability discipline that makes the platform deployable in classified contexts.