Command and Control

Sensors report objects; commanders act on relations. VIStology formalized what a situation is, then built SAWA — the reference system that monitors a commander’s standing relation as the situation evolves — and co-authored the battlespace-context framing with a serving U.S. Army scientist.

The Challenge: Context Is Not a Field You Add

The paper decomposes what “context” actually is, in doctrinal vocabulary rather than in the abstract. A report carries the SALUTE dimensions of FM 21-75 — size, activity, location, unit, time, equipment — to which the authors add a seventh, movement, because direction and speed are so often what decide an enemy course of action, plus two meta-dimensions that any system ingesting real reports has to carry: accuracy and credibility. The situation the report is read against is built from the Army's METT-TC factors of FM 3-0 — mission, enemy, terrain and weather, troops, time available, civil considerations — every one of them time-dependent. Behind both sits the relatively static body of knowledge: friendly and enemy doctrine, and the capabilities of Blue, Red and civilian equipment types.

And the factors do not decompose. That is the paper's structural finding, and it is why bolting a weather field onto a tracker is not context: “This implies that all contextual information needs to be considered in whole rather than as an isolated problem that can be handled separately.” A unit may fight one way in mountains, another way in snow, and a third way in mountains and snow.

Be clear about what that paper is and is not. It builds nothing and measures nothing — it is a conceptual framework, and its worked scenario is an analyst's chain of reasoning, not a system run. What it gives is the problem, stated precisely, by the government lab that owns it.

What a Situation Is, Formally

If the relations are the situation, then relations — and the situations they constitute — have to become first-class, computable objects, not a layer of application code sitting on top of a track store. That is what VIStology's Situation Theory Ontology does: it gives the core constructs of situation awareness a computer-processable semantics in OWL.

Same report. Three situations. One unattended ground sensor report — three wheeled vehicles at location L, moving due east at 25 kph — resolves into three different situations depending on the context it is read against. The observation is identical in all three branches; only the surrounding context differs. In the first branch the friendly mission is to hold a bridge 50 km to the west for two hours, so vehicles moving east are opening the range and the threat is negligible even if they are heavily armed. In the second, the sensor sits on a narrow wooded trail no large vehicle can pass, so the vehicles must be small — motorcycles or scooters — civilians were not all relocated, and no motorcycle-equipped unit appears in the enemy order of battle, so the likely reading is civilian motorcyclists. In the third, no friendly troops or civilians are near the sensor, the eastbound axis runs into the defended area within striking distance of the bridge and the defending troops, enemy doctrine is known to exploit civilian equipment, and heavy weapons on those vehicles would threaten the mission outright — a mission-critical threat. Each conclusion is written as an infon: an n-ary relation over objects plus an explicit polarity bit. The threat and no-threat readings are the same relation over the same objects, one bit apart. The decision the intelligence officer actually faces is whether to wake the commander or task the UAV and wait. Same Report. Three Situations. Sensors give you objects. The relations between them must be inferred — and the relations are the situation. The observation — one spot report identical in all three branches below — only what is known around it differs Unattended ground sensor (UGS) one SALUTE + M spot report 3 wheeled vehicles · location L · due east · 25 kph Size 3 · Activity moving · Location L · Unit — · Time T · Equipment wheeled · Movement 25 kph, due east That is the entire observation. A UGS cannot report affiliation, and it cannot give the unit or the unit type. 3 wheeled · L · due east · 25 kph the same nine values, unchanged 3 wheeled · L · due east · 25 kph the same nine values, unchanged 3 wheeled · L · due east · 25 kph the same nine values, unchanged The context — METT-TC factors plus doctrine and equipment knowledge, considered in unison MISSION Hold and defend bridge B. Every report the S2 reads is judged against that. TIME AVAILABLE Two hours, and shrinking. What happens after that is not this mission. TERRAIN B lies 50 km west of L. These contacts are moving east — opening the range, not closing it. ENEMY EQUIPMENT Immaterial here. They cannot reach B inside the window — armed or not. TERRAIN & WEATHER The UGS sits on a narrow wooded trail that will not permit the passage of large vehicles. EQUIPMENT — CIVIL & RED So the vehicles are small: perhaps motorcycles or powered scooters. The sensor never said so. CIVIL CONSIDERATIONS Not every civilian was relocated from this area, so civilian traffic is still possible here. ENEMY (ORDER OF BATTLE) No motorcycle-equipped unit appears in the Red order of battle. TROOPS & CIVIL No friendly troops near L; the civilians here were relocated. Confidence these are enemy: high. MISSION Their eastbound axis runs into our defended area — the bridge, and the troops holding it. RED DOCTRINE Red is known to exploit civilian equipment in innovative, asymmetric ways. ENEMY EQUIPMENT Heavy mortars or multiple RPG on those vehicles would threaten the mission outright. Negligible threat Probably negligible — even if they are heavily armed enemy units. ≪Threatens, Contact-1, BlueForce, 0≫ Civilian motorcyclists A few civilians on scooters — the thing you do not want to wake the commander for. ≪isCivilian, Contact-1, 1≫ A mission-critical threat Within striking distance of the bridge and of our defending troops. ≪Threatens, Contact-1, BlueForce, 1≫ One relation. One bit. Two opposite situations. ≪ R, a₁ … aₙ, polarity ≫ — an infon: an n-ary relation over objects, plus one explicit bit ≪Threatens, Contact-1, BlueForce, 1≫ and ≪Threatens, Contact-1, BlueForce, 0≫ are the same relation over the same objects, one bit apart. Polarity 0 is an assertion, not an absence — “not a threat” is a fact the system holds, stores and reasons with. Wake the commander — or task the UAV and wait? That is the decision. The report cannot answer it; only the relations inferred from it can. “While it is typical that information about objects … can be experienced, or observed directly, the relational information must be inferred.” Scenario: Powell (U.S. Army RDECOM CERDEC I2WD), Matheus, Kokar & Lorenz, FUSION 2006 — a worked analytical example, not a system demonstration. Representation: Kokar, Matheus & Baclawski, “Ontology-based situation awareness,” Information Fusion 10(1), 2009.
Figure 1. One unattended-ground-sensor report — three wheeled vehicles, location L, due east, 25 kph — and three different situations. The observation never changes; the context it is read against does. Under one mission the contacts are opening the range and the threat is negligible; under the terrain and the civil picture they are most likely civilians on scooters; under another mission, the enemy order of battle and Red doctrine, the same three blips are a mission-critical threat. Written formally, two of those readings are the same relation over the same objects, one polarity bit apart. Scenario from Powell, Matheus, Kokar & Lorenz (FUSION 2006), a worked analytical example, not a system demonstration; the infon notation is from VIStology’s Situation Theory Ontology work.

A situation is a fragment of the world — and that is the point

The formal core comes from situation theory — Barwise and Perry's, as formalized by Devlin — and VIStology's contribution was to give it a semantics a computer can process. A situation, in Barwise's words as quoted in our paper, is “a part of reality that can be comprehended as a whole in its own right.” Crucially it is not a possible world: it does not settle the truth of every proposition, only of the fragment you actually have. For anything fed by sensors and reports, that partiality is not a weakness of the theory — it is an accurate description of the operating condition. You never have the whole world. You have a fragment, and you must be aware anyway.

A situation is tied to the information it makes factual by the supports relation, written s ⊨ σ: the situation s supports the item of information σ. We are careful about how far that mapping goes, and the paper says so itself — because OWL's semantics is classical and model-theoretic, the formalization “can be claimed to resemble situation theory rather than faithfully implement it.” A correspondence, stated honestly, is worth more to an evaluator than an equivalence that will not survive inspection.

Infons: a relation, its objects, and one explicit bit

The unit of information is the infon, written ≪R, a₁, …, aₙ, polarity≫ — an n-place relation, the objects standing in it, and a polarity of 1 or 0. That last slot is not bookkeeping. Polarity 0 is an assertion, not an absence. “This contact is not hostile” is a fact the system holds, stores, transmits and reasons over, rather than a hole in the data indistinguishable from “we have not looked.” Two situations can carry identical kinematics and differ in exactly one polarity bit — and that bit is the difference between a threat and a formation exercise.

Infons come in two flavors and the distinction is the fusion pipeline in miniature. Observed infons are the ones a sensor or a source hands you: positions, velocities, equipment types. Derived infons are everything else — near, closing on, threatens — inferred from observed infons and from each other, in chains. Level one gives you the first kind. Only reasoning gives you the second, and the second is the situation.

Recognizing a situation is classifying it

What does it mean, formally, for a system to know it is looking at an ambush? In situation theory an agent reasons by applying constraints, which link one situation type to another and which — in the paper's own phrase — “play the role of laws of the world, e.g., physical laws.” The engineering move is to render those constraints as OWL subclass axioms between situation types. Recognizing a situation then becomes subsumption: deciding which situation types the current situation belongs to, using a standard reasoner rather than a bespoke detector.

That is the payoff for a customer. Your doctrine, your rules of engagement, your platform limits stop being conditionals buried in application code and become machine-checkable axioms that a reasoner enforces and an auditor can read. And it is why hand-coding will not scale: “Because there are so many possible relations, it is impractical to expect that procedures could be written for all potential relations.”

OWL alone does not reach far enough — it cannot compose properties or express joins — so the concepts beyond it are captured as rules. The paper's own, in its neutral notation, are as plain as this:

  • If near(X,Y) and inDirectionOf(X,Y) Then chases(X,Y)
  • If belongsToSpecies(X,S) and belongsToSpecies(Y,T) and preysOn(S,T) and sees(X,Y) Then chases(X,Y)

Those rules were run on BaseVISor, VIStology's forward-chaining inference engine for RDF/OWL triples — named in print in our most-cited paper, where it processed RDF and RDFS semantics together with R-Entailment, a decidable subset of OWL. The engine we still build and ship is the engine that paper names. What it did there was small — two rules, a handful of individuals, the expected fact derived and the situation classified. No benchmark, no numbers, and we will not invent any.

The ontology is the interlingua between the human and the machine

Machine situation awareness exists to serve a human one, which is why the model on the machine's side has to be commensurable with the model in the commander's head. In IEEE Intelligent Systems, VIStology's president, Mieczyslaw Kokar, and Mica R. Endsley — originator of the field's canonical three-level model of situation awareness — argue exactly that: the human's mental model and the machine's computer model “both can be viewed as types of cognitive models,” and a shared ontology is the medium in which they exchange situation descriptions. Protocol interoperability is not enough: “To achieve common goals, the computer and human agents need to have both a shared understanding of the goals and a shared understanding of what is relevant for a particular goal.”

There is an operational dividend hiding in that. If two agents share the ontology and can each infer, only the delta has to cross the link — “the implicit information was inferred by the agents locally.” In a contested, low-bandwidth, intermittently-connected network, sending a partial situation description that the receiver can complete is worth a great deal more than shipping a full picture you cannot afford to send.

The Reference System: SAWA

The theory has a system behind it. SAWA — the Situation Awareness Assistant — was built by VIStology, then operating as Versatile Information Systems, Inc., and published at the SPIE multisensor and multisource information-fusion conference with three co-authors from the Air Force Research Laboratory in Rome, New York. Five of its eight authors sit on VIStology's side of the byline; three are government researchers, as authors and not as acknowledgees.

SAWA — the Situation Awareness Assistant The SAWA architecture. An offline knowledge-management suite — Protégé with the ezOWL plug-in for ontology editing, VIStology's ConsVISor OWL and RDF consistency checker, and VIStology's graphical rule editor RuleVISor — authors the domain knowledge on top of the SAW Core Ontology, the upper ontology every domain class subclasses. That domain knowledge, ontologies plus rules, feeds the runtime SAWA Engine, implemented in Java over Jess with a proprietary parser. The engine's input is simulated level-1 object data: hand-authored OWL snapshots of the world state at successive time slices, from a simulator of fused level-one object data, not a live sensor feed. Inside the engine, the Situation Management Component is the controller and performs relevance reasoning, selecting the relevant rules for the Relation Monitoring Agent and the relevant objects and attributes for the Event Management Component. The Event Management Component ingests the event stream and fans it out in three encodings: relevant events to the Relation Monitoring Agent, all events as OWL triples to the Triples DataBase, and relevant object-attribute instances to the graphical user interface. The Relation Monitoring Agent runs the rules in a forward-chaining Rete network under Jess; a rule firing instantiates a relation. The Triples DataBase keeps the full event history and supports what-if queries. The operator states a standing relation — monitor hasSupplyLine for all friendly units — and the interface reports which units still have one. The demonstrated scenario is military supply logistics: a region that has a supply station and is under friendly control is suppliable, and suppliability propagates recursively across passable roads to any unit in a suppliable region. No evaluation is reported: no accuracy, no timing, no scale, and every relation was reported at certainty 1.0. SAWA — A Situation Awareness System, Built and Run Knowledge authored offline; a runtime engine that monitors the relations that hold as the situation changes Co-authored with the Air Force Research Laboratory, Rome NY — Hinman · Salerno · Boulware The input Offline — knowledge management: authoring the domain knowledge simulated Level-1 object data Hand-authored OWL snapshots of the world state at successive time slices — from “a simulator of fused level-one object data.” No live sensor feed. SAWA in this paper never touched a real sensor. Protégé + ezOWL ontology editor (its OWL output gets checked) VIStology ConsVISor OWL / RDF consistency checker — its symptom reports are themselves OWL VIStology RuleVISor graphical rule editor — rule terms type-checked against the ontology SAW Core Ontology — Situation · Object · Relation · Attribute · Event · Goal · Rule the upper ontology every domain class subclasses — which is what keeps the engine generic the event stream domain knowledge — ontologies + rules The SAWA Engine Java · Jess (Rete) · RDF/OWL/XSD parser SMC — Situation Management Component the controller. Relevance reasoning selects the relevant rules → RMA and the relevant objects & attributes → EMC; it is the channel between GUI, TDB and RMA. EMC Event Management Component Ingests the event stream, annotated against an Event Ontology known only to the EMC — so the source can be swapped without touching the engine. Fans it out three ways → RMA — Relation Monitoring Agent ← relevant events, as Jess-formatted triples Rules run in a forward-chaining Rete network (Jess). A rule firing instantiates a relation. TDB — Triples DataBase ← all events, as OWL triples The full event history, queryable. What-if: assert hypothetical facts, query, then retract them and everything deduced from them. GUI ← the relations that hold (via the SMC) ← relevant object–attribute instances Standing-relation selector. Relevant-relations table. Situation object map — friendly units, a hostile unit, roads, regions. The operator watches the relations. the relations that hold, now the goal · queries The operator States the standing relation — the goal: monitor hasSupplyLine for all friendly units and queries the history — including what-if: assert a hypothesis, query, then retract it and all it implied. The demonstrated scenario — military supply logistics hasSupplyStation ∧ underFriendlyControl isSuppliable hasSupplyLine isSuppliable propagates recursively across passable roads — the rule set bounds the recursion depth. Six friendly units including a supply station, and one hostile unit. As units move and roads change hands, the set of units that still has a supply line changes — and the system reports it, time slice by time slice. No evaluation is reported — no accuracy, no timing, no scale. Every relation was reported at certainty 1.0; SAWA did no uncertainty reasoning. Matheus, Kokar, Baclawski, Letkowski, Call, Hinman, Salerno & Boulware, “SAWA: An Assistant for Higher-Level Fusion and Situation Awareness,” Proc. SPIE, 2005
Figure 2. SAWA, redrawn from the 2005 SPIE architecture figures. An offline suite — Protégé/ezOWL, VIStology’s ConsVISor consistency checker and its RuleVISor rule editor — authors ontologies and rules on top of the SAW Core Ontology, and the runtime engine does the rest: the EMC ingests the event stream and fans it out; the RMA fires the rules in a forward-chaining Rete network; the TDB keeps the full history and answers what-if queries; the SMC’s relevance reasoning narrows the rules and the data to what the operator’s goal actually needs. The operator declares a standing relation — monitor hasSupplyLine for all friendly units — and the system reports which units still have one as the situation evolves. The input was simulated: hand-authored OWL snapshots of the world state, not a live sensor feed. Three of the eight authors are from the Air Force Research Laboratory, Rome NY.

The operator states a standing relation; the system configures itself to it

Monitoring every possible relation is not merely expensive, it is impossible — “the number of potentially relevant relation types is practically unlimited.” SAWA's answer is to start from what the user needs to know. The operator declares a standing relation — the goal — and the Situation Management Component performs relevance reasoning against it, passing the relevant rules to the Relation Monitoring Agent and the relevant objects and attributes to the Event Management Component. In the authors' words: “By knowing more specifically what the user is looking for, automated systems can focus attention on just those events and candidate relations that are relevant,” so that “the large number of objects and attributes in a situation can be pared down to a more manageable stream of data.”

Read that as a commander's critical information requirement and the architecture snaps into focus: state the requirement, and the fusion system decides for itself which knowledge to load and which data to watch in order to service it.

A supply line is a derived relation, not a measured one

The scenario is military supply logistics, and the standing relation is hasSupplyLine for all friendly units — where a supply line is a continuous path of roads under friendly control connecting a unit to a supply station. Nothing observes that. It is built by rules, in a chain: a region that has a supply station and is under friendly control is suppliable; suppliability then propagates recursively across passable roads to neighboring regions; and any unit sitting in a suppliable region has a supply line. Control and passability are themselves inferred, not read off a sensor.

Then the world moves. Units reposition, roads close, regions change hands — and the set of relations that hold changes with them. What the paper reports is exactly this: “The system correctly detected the standing relations that held true at each time slice and reported these back to the GUI which displayed them for the user.” A unit whose supply line disappears is a sustainment decision — reroute, resupply, or reposition before it is isolated — and it is the system, not the map, that noticed.

The whole runtime is five named components — SMC, EMC, RMA, TDB and GUI — fed by an offline knowledge-management suite of three: an ontology editor, VIStology's ConsVISor consistency checker, and a graphical rule editor that type-checks every rule term against the ontology as it is authored. Domain ontologies plug in by sub-classing the SAW Core Ontology, which is what lets the engine stay generic across domains.

What SAWA was not — and we will not say otherwise

A defense evaluator is entitled to the boundaries, so here they are, from the paper itself.

  • The input was simulated. The event stream came from “a simulator of fused level-one object data”: hand-authored OWL snapshots of the world state at successive time slices. SAWA in this work never touched a live sensor feed, and we do not claim it did.
  • No evaluation is reported. There is no accuracy figure, no timing, no throughput, no scale study and no baseline anywhere in the paper. Its empirical claim is the single sentence quoted above — evidence that the system ran end to end, and nothing more.
  • No uncertainty reasoning. Every relation the system instantiated carried a certainty of 1.0. The plumbing for per-attribute certainty was in the input schema, but the reasoner of that era did not use it.
  • The reasoner was a rule engine of its time — declarative rules compiled into a forward-chaining Rete network (Jess), with a proprietary RDF/OWL/XSD parser, in Java. It is not the engine we ship today, and this page does not backdate one into the other.

What remains after all of that is still the point: an end-to-end situation-awareness system, built and run on a military scenario, that monitored a relation no sensor can measure and reported it to an operator as the situation evolved — with the Air Force Research Laboratory on the byline.

Proof Points

Air Force

SAWA — Built with AFRL Rome

The reference situation-awareness system: five runtime components, three knowledge-management tools, a domain-independent core ontology, and a military supply-logistics scenario in which the system reported which friendly units still held a supply line as the situation changed. Published with three co-authors from the Air Force Research Laboratory, Rome, New York — government researchers as authors, not acknowledgees. Honest boundaries, from the paper: the input was simulated OWL world-state snapshots, every relation came out at certainty 1.0, and no evaluation is reported.

U.S. Army

The C2 Problem, Lead-Authored by the Army

Gerald M. Powell of U.S. Army RDECOM CERDEC I2WD, then at Fort Monmouth, New Jersey, is the first author of our FUSION 2006 paper on the interpretation of battlespace intelligence — with Matheus (VIStology), Kokar (Northeastern) and Lorenz (EWA Government Systems). Its primitives are the Army's own: SALUTE spot reports from FM 21-75, METT-TC factors from FM 3-0, priority intelligence requirements, enemy courses of action. The doctrine is not borrowed vocabulary; it is the paper's native language. It is a conceptual framework and it builds nothing — its value is that the government lab that owns the problem stated it with us.

Selected Publications

SAWA: An Assistant for Higher-Level Fusion and Situation Awareness

Matheus, C.J., Kokar, M.M., Baclawski, K., Letkowski, J., Call, C., Hinman, M., Salerno, J. & Boulware, D.

SPIE Conference on Multisensor, Multisource Information Fusion (2005)

View PDF

Understanding the Role of Context in the Interpretation of Complex Battlespace Intelligence

Powell, G.M., Matheus, C.J., Kokar, M.M. & Lorenz, D.

FUSION 2006

View PDF

Situation Awareness and Cognitive Modeling

Kokar, M.M. & Endsley, M.R.

IEEE Intelligent Systems 27(3):91-96

View Publication

See the full list of VIStology publications →

Related

Situation Awareness & C2 The solution this use case belongs to Knowledge Retrieval & Relevance The sibling use case: relevance as a proof obligation Ontology Development The modeling craft behind the SAW Core Ontology BaseVISor VIStology’s forward-chaining inference engine All Publications The full research record

Put the Relations on the Screen

If your operators see tracks but need situations — supply lines, threats, relations that bear on the order — we can help you make them computable.

Get in Touch