More Than a Better Mousetrap: The Data Core Behind Integrated Air Defense, Part II

In Part One of this this three part series, I discussed the nature of the integrated air defense problem, introduced the associated cognitive processes and collates them within the knowledge management process.

Part Two, below, discusses middleware tools applicable to integrated air defense systems and sets out a notional architecture for a middleware powered integrated air defense system.


IADS Automation Middleware

A successful IADS system must integrate software components that automate the three cognitive processes outlined in Part One (i.e., situational awareness (SA), sensemaking and wisdom application).  Obviously the components must be highly performing in terms of throughput and bandwidth use, robust and scalable.  Fortunately, the middleware industry has developed knowledge management solutions for commercial industry that readily translate to the IADS problem space:

• Deriving SA from large volumes of real-time data is achieved by filtering the data in real-time to identify operationally relevant events through the use of event processors;
• Sensemaking occurs when business rules are applied to relevant events to create operationally relevant knowledge by business rule servers; and
• Wisdom is applied when experience (in the form of organizational processes and procedures) is applied to knowledge to create and implement optimized courses of action by business process managers. 

Complex Event Processors

Vendor	Product	Licensing
Espertech	Esper (Java) Nesper (.NET)	Open Source; GNU General Public License
Oracle	Oracle Event Processing	Proprietary
IBM	WebSphere Business Events	Proprietary
WSO2	WSO2 Complex Event Processor	Open Source; Apache License

Business Rules Servers

Vendor	Product	Licensing
Progress	Corticon BRMS	Proprietary
Oracle	Oracle Business Rules	Proprietary
InRule Technology	irServer	Proprietary
WSO2	WSO2 Business Rules Server	Open Source; Apache License

Business Process Managers

 

Vendor	Product	Licensing
Software AG	webMethods BPMS	Proprietary
Oracle	Oracle Business Process Management	Proprietary
IBM	IBM WebSphere Process Server	Proprietary
WSO2	WSO2 Business Process Server	Open Source; Apache License

It’s worth a quick look at how each of these products functions before delving into the information architecture of a notional IADS. 

Event processors listen to events and detect patterns based on predefined rules in near-real time. They do not store all the events. (Event storage for later exploitation is the province of business activity monitors.)  There are three basic models:

• Simple event processing, which implements simple filters (“Is this aircraft friendly or hostile?”)
• Event stream processing (ESP), which aggregates and joins multiple event streams; and
• Complex event processing, which processes multiple event streams to identify meaningful patterns using complex conditions and temporal windows (“There have been aircraft detected AND the aircraft are of a given type AND the aircraft are in a given area AND the aircraft have failed IFF interrogation”).

Complex event processors (CEP) are designed to process tens of thousands (or more) events per second with a latency of milliseconds or less.

Business rules provide meaning and guidance for an organization’s activities based on any given set of facts.  Business rules servers (BRS) use a data stream to define the nucleus of facts upon which rules (declaratively defined conditions or situations) will operate and identify the actions to be taken, or inferences to be derived based on the results of applying the rules.  The rules server allows for the operational or business logic to be externalized and abstracted to a higher level, allowing operational users (i.e., uniformed service personnel) to manage them (as opposed to programmers). 

Business process managers (BPM) have both design-time and runtime capabilities.  During design-time, they allow operational users to envision, define, control and adapt the courses of action that will be taken in response to any given set of events.  During runtime, these tools execute the operational workflows in a manner compliant with standards such as WS-BPEL and WS-HumanTask.  More importantly, they allow for the coordinated execution of operational workflows with many different enterprise services and human interactions. 

The Middleware Powered IADS –  Notional Architecture 

Now that we’ve collected the pieces and capabilities for an IADS, let’s see how they fit together.  We’ll start by setting out the pieces of our (simplified for illustrative purposes) IADS.  We have:

•  Targets, which are any aircraft that can potentially be engaged by the IADS;
•  Acquisition sensors, which detect, identify and locate potential aerial targets;
•  Tracking sensors, which lock onto and provide precise targeting information on a specific aerial target;
• Weapons, which span the range from surface to air missiles (SAM) to AAA and directed energy weapons; and 
• C5I nodes, which orchestrate, control and manage AAW engagements for a distributed IADS.

IADS Operational View

During normal operations, acquisition sensors are constantly sweeping the skies.  They send a continual series of data streams to the C5I node, including contact, IFF, system health and status and logistics reports.  These reports represent events that are evaluated in real-time by the IADS’ CEP.  Many patterns identified by the CEP are simply discarded.  For example, a biological contact identified as a flock of seagulls is of no interest to air defenders.

Other patterns are passed to the BRS for additional processing.  In peacetime, the only rule sets analysis results received may be those requiring the BPM to invoke a storage process to be invoked for audit and logging purposes.  A commercial aircraft flying an established airway on a scheduled route may generate contact and IFF events, but it will not trigger any military action, but command guidance could require that the fact of the aircraft’s passage be logged.

It is during a hostile event that all the components of the IADS come into play.  The CEP receives contact report events that correlate with negative IFF report events from the acquisition sensors.  The resultant patterns indicate hostile action, and are passed to the business rules server.  The BRS applies logic along the lines of:

•  Are the incoming aircraft hostile?  YES.
•  If no, log event.
• If yes, identify the defense sector to which the aircraft are heading.

•  Are they heading to sector A?  NO.
•  If no, evaluate against sector B
•  If yes, alert tracking radars 1, 3, 5 and 9
•  If yes, alert SAM sites 22, 34, 18 and 15
•  If yes, alert AAA sites 345, 928 and 220
•  If yes, log event

•  Are they heading to sector B?  YES.
• If no, evaluate against sector C
• If yes, alert tracking radars 2, 4, 7 and 8
• If yes, alert SAM sites 77, 51, 92 and 76
• If yes, alert AAA sites 999, 226 and 262
•  If yes, log event

Each time that the BRS indicates that a process action is necessary (e.g., alert, log, etc.), information is passed to the BPM, which invokes the necessary process.  In this case, alerting information is sent to tracking sensors and weapons. 

IADS System Functionality View

 
Once actuated, the tracking sensors begin sending a continual stream of data back to the C5I nodes, which again, employ the CEP, BRS and BPM.  Identified event patterns in this case might include the fact of a successful lock on by a tracking radar and the arrival of a locked target within range of one or more weapons.  The BRS might employ a logic chain that looks like this: 

•  Is the target within range of any weapon systems? YES.
• If no, re-evaluate target in 0.5 seconds
• If yes, identify weapon systems within range
• If yes, is target suitable for SAM? YES.
• If no, evaluate target against AAA 
• Identify SAM sites within range.
• Identify SAM sites in ready to launch status
• Identify number of missiles remaining on each SAM site in ready to launch status 
• Prioritize SAM sites by number of missiles remaining 
• Send weapons free command to SAM site with greatest number of missiles remaining

In this case, the BPM was instructed to instantiate logistics processes (e.g., which weapons are in what locations, supply status) as well as health and status processes (e.g., who is in ready to launch status) and operational processes (e.g., send weapons free order).

Launch events are reported to the C5I node by the weapons, which also report the success or failure of each engagement.  The BRS may play a role by evaluating the results of the engagement with respect to the need to re-engage (i.e., Was the engagement successful? If no, re-engage and log result. If yes, go to weapons tight and log result.), whereas the BPM will be responsible for executing logging processes and sending operational commands.

I hope you enjoyed Part II  of this series, and found it informative.  Please come back for Part III on Friday, 25 January 2013, in which I will be discussing  available middleware options, provide illustrations of real world integrated air defense systems and offer some concluding thoughts.