Electronic order of battle management: EOB databases, emitter identification and change detection

An electronic order of battle (EOB) is the structured intelligence record of an adversary's electromagnetic capabilities: which radars and electronic warfare systems are deployed, on which platforms, with what measured parameters, at which locations, and with what confidence. Unlike a static emitter library used for real-time threat warning, an operational EOB is a living database — continuously updated by ELINT collection, managed through formal change detection processes, and used to drive the next collection cycle. This article covers the complete management lifecycle of an EOB database, from the data model and emitter identification algorithms through platform association, change detection, collection tasking, and the database architecture that makes coalition sharing possible.

What the EOB contains and why it matters

The electronic order of battle is distinguished from a simple threat library by its organizational structure and its provenance depth. A threat library records what a radar type can do — its parameter ranges and operating modes as measured from all known examples. The EOB records what specific emitters are doing right now: which individual systems are deployed, where, in what operational status, and with what degree of confidence derived from specific collection events at specific times. This distinction is operationally critical. A threat library tells a mission planner where a surface-to-air missile type might threaten. The EOB tells them whether that specific battery is currently active, at what grid reference it was last observed, and how recently that observation was made.

Each EOB entry covers one emitter — a single radar or electronic warfare system — and groups together everything known about it from all collection sources and all collection times. The core elements of an EOB entry are: the emitter identification (EI) number as its unique database key; the technical parameters measured from ELINT collection with their uncertainty bounds; the platform record linking the emitter to its host vehicle, aircraft, or vessel; the geographic operating area with its positional error ellipse; the operational status (active, inactive, suspected destroyed, unknown); and the collection provenance record that traces each data element to the specific collection events that produced it. Confidence is a per-field attribute, not a single flag on the record — the frequency range of a well-studied radar may be known to very high confidence while its current geographic position, last observed a week ago, carries significant uncertainty.

The EOB supports several downstream operational functions simultaneously. Threat warning systems electronic warfare use EOB data as the reference library against which observed emissions are matched during a mission, generating cockpit or shipboard warnings when a known threat emitter is detected. Electronic warfare planning draws on the EOB to identify which threat emitters must be suppressed, deceived, or avoided for a mission to succeed. Intelligence assessments of adversary force disposition and capability are built directly from EOB trend data — the appearance of a fire-control radar at a new location, or the activation of a previously inactive emitter type, carries immediate intelligence value. Route planning tools compute radar coverage maps from EOB emitter positions and parameters to identify low-observable corridors. Each of these downstream functions places different demands on the EOB — they need different data, at different confidence thresholds, updated at different rates — and a well-designed EOB architecture serves all of them from a single authoritative source.

Emitter record data model

The emitter identification (EI) number is the persistent unique key for an EOB record. Unlike a collection event reference — which identifies a single intercept — the EI number persists across all observations of the same emitter over its entire operational life. Most operational EOB systems structure EI numbers hierarchically: a country or theater prefix, a system family code identifying the radar or electronic warfare system class, and a unique instance suffix distinguishing individual units of the same type. When a new observation cannot be correlated to an existing EI number — no existing record matches the measured parameters within the correlation threshold — the EOB management system opens a new record in tentative status, assigns a provisional EI number, and queues the record for analyst confirmation before it is promoted to the active EOB.

The parametric data fields for each emitter record are organized by measurement category. Radio frequency fields record the observed minimum and maximum carrier frequency, the frequency agility pattern (fixed, sequential stepped, random), and the inter-pulse frequency step size where applicable. Timing fields record the pulse repetition interval with its minimum, maximum, and most probable values, the PRI agility type (fixed, staggered with specific ratios, jittered, dwell-and-switch), and pulse width. A representative field structure for a simple pulsed radar looks like this:

Antenna scan fields record the scan type (circular, sector, conical, phased-array stare, track-while-scan), scan period range, and beam shape descriptors where determinable from the amplitude envelope. Modulation fields record intra-pulse modulation type (simple pulse, linear frequency modulation, binary phase coding), LFM chirp bandwidth and direction, and pulse compression ratio. The polarization field records measured antenna polarization where the collection geometry permits it. Each numerical field stores not a single value but a distribution: the observed minimum and maximum across all collection events, the most probable value from the weighted measurement distribution, and the confidence weight derived from the number, quality, and consistency of the observations. A field derived from a single low-quality collection event is stored with a wide uncertainty bound and a low confidence weight, making it visually and algorithmically distinguishable from well-characterized fields.

Source and confidence fields for each parameter record the number of collection events contributing to the parameter estimate, the collection asset types (ground station, airborne, space-based), the most recent observation timestamp, and a quality indicator for the measurement geometry. The provenance record links each field to the specific collection event IDs that contributed observations, enabling reprocessing if a collection source is later found to have introduced systematic measurement error.

Parametric emitter identification

Parametric emitter identification determines the type of radar or electronic warfare system that produced an observation by comparing the extracted signal parameters against an emitter type library. The task is fundamentally a classification problem: given a parameter vector — frequency, PRI, PW, scan type, modulation — find the library entry whose parameter bounds best match the observation, accounting for measurement uncertainty in both the observation and the library entry. The classification output is not a binary match or no-match but a ranked list of candidate types with associated confidence scores.

The classical nearest-neighbor approach computes a weighted Mahalanobis distance between the observation and each library entry. Each parameter dimension is weighted by the inverse of its combined variance — the sum of the observation measurement variance and the library entry's parameter variance. A parameter measured with high precision from a strong signal contributes more weight to the identification score than one with wide uncertainty. Formally, for observation vector x and library entry l with combined covariance matrix S, the identification score is:

Machine learning classifiers extend nearest-neighbor identification in important ways. ELINT signal parameter extraction produces features beyond the basic parametric set — intra-pulse modulation details, spectral characteristics, amplitude envelope shape — that linear distance metrics do not capture well. Gradient-boosted tree classifiers trained on large synthetic parameter libraries handle nonlinear feature interactions: the specific combination of frequency agility pattern, PRI stagger ratio, and scan type may uniquely identify a system even when no individual parameter falls within a uniquely identifying range. Neural network classifiers operating on raw pulse descriptor sequences provide further generalization to emitter variants not explicitly represented in the training set.

Confidence scoring for the classifier output must be calibrated against actual identification accuracy, not raw classifier posterior probabilities. A gradient-boosted classifier trained on a library of 200 emitter types may produce a highest-class probability of 0.82 for an observation that is actually an out-of-library emitter type — the 0.82 reflects the classifier's certainty given its training distribution, not the probability that the identification is correct given all possible emitter types that might be observed. Operational EOB identification pipelines apply isotonic regression or Platt scaling to calibrate classifier probabilities against held-out validation data, and add an explicit out-of-library detector that flags observations that fall in low-density regions of the feature space as potential unknown emitter types rather than forcing a match to the closest library entry.

Platform-emitter association

Platform-emitter association is the process of linking individual emitter records to the specific vehicle, aircraft, or vessel that carries them. Most military platforms carry multiple emitters that operate simultaneously or in rapid alternation. A surface combatant typically runs a navigation radar, a surface search radar, and a fire control radar concurrently. An integrated air defense unit deploys search radars, target acquisition radars, tracking radars, and guidance uplinks that are operationally linked even when not spatially collocated. Association enables the EOB to model these multi-emitter systems as a unit — making it possible to say "the following three emitters constitute the radar suite of platform class Y" and to track the entire suite as that platform moves and operates.

The primary association method is co-emission analysis. Emitters that are consistently observed at the same geographic position during the same collection time windows are inferred to be collocated. Co-emission is scored across multiple collection events: a single co-observation could reflect geographic proximity rather than platform co-location, but fifteen independent co-observations with position agreement within the geolocation uncertainty of each collection event provide strong evidence. The co-emission score accounts for the fact that emitters on the same platform may not operate simultaneously — a fire-control radar activates only when tracking a target, and its absence during a collection that captures the search radar does not break the association if prior collections confirmed co-location.

Evidence weighting for different association methods assigns different confidence values to each evidence type. Co-emission from two or more independent collection geometries in a single collection event provides the strongest single-event evidence, because it rules out geometry-driven geolocation error as an alternative explanation for the position agreement. Movement correlation over multiple time periods — an emitter track matching a platform movement track from maritime patrol aircraft or other sensors — provides strong temporal evidence but requires a long observation baseline. Parametric loadout matching — the set of emitters associated with a geographic position matches the known equipment specification for a specific platform class — provides structural evidence that helps confirm an association suggested by co-emission. Multi-intelligence fusion that connects an ELINT emitter track to a COMINT communications emitter and both to an imagery-confirmed platform identification provides the highest confidence of all, but requires the collection and processing resources to achieve that fusion.

The platform association record in the EOB stores all of this evidence explicitly. Rather than recording only the asserted platform type, the EOB records the specific collection event references that contributed association evidence, the evidence type and confidence weight for each, and the analyst review record where a human approved or modified the automated association. This provenance enables the association to be revised if new evidence contradicts it — for instance, if movement tracking later shows the emitter reached a location faster than the associated platform type can travel, the association is flagged for re-evaluation.

EOB change detection and alerting

EOB change detection is a systematic real-time comparison between incoming collection events and the established EOB baseline, designed to identify operationally significant developments and route alerts to the appropriate consumers. The detection operates across four change categories, each with distinct detection logic and alert priority rules.

New emitter detection fires when a collection event produces a parameter vector that fails to correlate with any existing EOB record above the correlation acceptance threshold. The new-emitter alert is classified by the implied threat level of the closest matching emitter type in the library — if the closest library match is a fire-control radar for a surface-to-air missile system, the new-emitter alert carries a higher priority than if the closest match is a navigation radar. The geographic position of the new emitter is checked against priority intelligence requirements to determine whether the location is of immediate operational interest. High-priority new-emitter detections generate immediate alerts; lower-priority new emitters are queued in a daily new-emitter report.

Parameter drift detection monitors known emitter records for shifts in measured parameter values beyond the established historical distribution bounds. A radar changing its PRI mode — switching from a fixed PRI to a staggered PRI — may indicate a software update, hardware modification, or a new operating mode that was not previously observed. Frequency agility pattern changes may indicate counter-ELINT measures or operational mode changes. The drift detection threshold for each parameter is set relative to the historical measurement variance of that emitter: a parameter that has been observed with very stable values requires a smaller change to trigger a drift alert than one that has shown natural variation. Confirmed parameter drift updates the emitter's parameter record and generates a change report for downstream consumers holding the prior parameter values.

Platform redeployment alerts are generated when an emitter previously associated with a geographic area is observed at a location outside that area. The displacement threshold is computed from the combination of the emitter's historical operating area, the positional uncertainty of the new observation, and the time elapsed since the last observation — a large displacement in a short time is more significant than the same displacement over a longer period during which movement was plausible. Redeployment alerts feed directly into SIGINT collection tasking management to schedule follow-up collection at the new location and confirm the redeployment.

EOB version control supports change detection by maintaining a complete history of every emitter record state, timestamped and linked to the collection events that caused each change. The version history enables baseline selection — the change detection system can compare the current state against the EOB as it stood one week ago, one month ago, or at a specific operational event — and supports rollback if an update is later found to have been incorrect. Version deltas between EOB snapshots are the primary mechanism for distributing updates to downstream consumers with narrow-bandwidth datalinks: rather than retransmitting the full EOB, the system transmits only the records that changed since the version the consumer holds.

Collection tasking from the EOB

The EOB drives the collection cycle in two ways: priority emitter list generation, which identifies which emitters most need updated collection, and collection gap analysis, which identifies which priority emitters are not currently covered by scheduled collection assets. Together these processes close the intelligence production loop — the EOB is not just a product of collection but the primary input to the tasking decisions that direct future collection.

Priority emitter list generation selects emitters from the EOB for collection attention by scoring them against several criteria. Threat priority derives from the emitter's type and its operational role — a fire-control radar for an integrated air defense system is higher priority than a navigation radar regardless of its parameter confidence. Currency gap scores emitters whose last observation is older than a threshold relative to their expected operational tempo — a highly mobile system last observed two weeks ago has a larger currency gap than a fixed-site system last observed at the same time. Confidence deficit scores emitters whose parameter confidence scores are below the acceptable threshold for the operational uses consuming that data — a route planner needs high-confidence position and frequency data, and emitters that fall below those thresholds are scored high on the collection priority list. Intelligence requirement linkage directly elevates any emitter explicitly named in a current collection requirement to the priority list regardless of its other scores.

The combined priority score for each emitter is computed as a weighted sum of these criteria, with weights set by the collection management cell to reflect current operational priorities. The output is a ranked priority emitter list that is refreshed on each collection planning cycle. The collection planning tool maps the priority emitter list against the available collection asset schedule — which ground stations cover which geographic areas, which airborne assets are available for tasking during which windows, and what frequencies each asset can cover — to produce a coverage matrix showing which priority emitters have current collection coverage and which do not.

Gap analysis identifies the unmatched cells in the coverage matrix: high-priority emitters with no scheduled collection coverage during the planning window. For each gap, the analysis tool generates a tasking recommendation specifying the emitter EI number and geographic area, the required collection parameters (frequency band, dwell time, minimum SNR requirement), the time window during which collection would be most productive (based on the emitter's historical activity schedule), and the collection asset best suited to close the gap. The tasking recommendation is not a direct command — the collection manager reviews it, considers competing demands on the same assets, and issues the final collection order — but it encodes all the EOB-derived intelligence needed to make an informed tasking decision. The feedback loop closes when collection events assigned to EOB tasking recommendations return through the ingestion pipeline and update the targeted emitter records, improving their confidence scores and triggering a new gap analysis cycle.

EOB database architecture and dissemination

The EOB database schema must accommodate the full epistemic structure of the intelligence it contains — not just current best estimates but the observation history, confidence trajectories, and provenance chains that give the data its analytical meaning. A minimal production schema has five primary tables. The emitter table is the master record: EI number, system designation, function code, operational status, entry confidence, and last update timestamp. The parameter table stores each measured parameter as a separate row keyed by EI number and parameter type, with columns for the minimum value, maximum value, most probable value, confidence weight, observation count, and last observation timestamp. The observation table stores each individual collection event linked to an EI number, with measurement values, measurement uncertainty, collection asset identifier, geometry descriptor, and the processing pipeline version that produced the measurement. The platform association table records each emitter-platform link with its evidence type, confidence weight, evidence event references, and analyst review record. The version table snapshots the emitter and parameter tables at each update commit, supporting version delta generation and rollback.

Classification handling within the EOB is one of its architecturally complex requirements because different elements of the same emitter record carry different classification levels and different releasability caveats. The technical parameters of a well-studied radar derived from widespread airborne ELINT may be releasable to coalition partners; the specific emitter identification fingerprint derived from sensitive collection means may be held at a higher classification level; the platform association confirmed by overhead imagery may carry access restrictions independent of its classification level. The EOB schema implements this by storing classification and releasability attributes at the field level — in the parameter table for technical parameters, at the association record level for platform associations — rather than as a single attribute on the emitter record.

Coalition sharing extracts are generated by a releasability-aware export process that evaluates each field's releasability attribute against the recipient partner's sharing agreement, redacts or replaces fields the recipient is not authorized to receive, and produces a formatted extract containing only authorized data. The extract format used for coalition sharing is typically a standard ELINT data exchange format — NATO's MAJIIC data model, for instance, provides a standardized XML schema for EOB exchange among alliance members. The releasability evaluation is performed at export time, not at ingestion time, so the authoritative EOB always contains the most complete available data and export policies can be updated without modifying the underlying records.

Dissemination architecture for operational EOB consumers must balance currency against bandwidth. Tactical consumers on narrow datalinks cannot receive full EOB refreshes on every collection cycle. The version delta mechanism generates change-only updates — a structured message listing only the emitter records that changed since the version the consumer holds — reducing the data volume proportionally to the fraction of records that changed. Consumers register their current version number with the dissemination system, which maintains a per-consumer version pointer and generates the appropriate delta on each update cycle. Emergency updates — new emitter detections and redeployment alerts for high-priority systems — bypass the delta cycle and are pushed immediately to all registered consumers with a priority flag, ensuring that operationally critical changes reach tactical users within the latency envelope their decision cycles require.