The central thesis for the Blueforce IoT and shared situational awareness software platform began to form in 2008 after a meeting with a US DoD special operations commander who described a problem he was experiencing; one that we had heard several years prior during the early days of Operation Iraqi Freedom (OIF). This special operations group deployed with 18 or more body-worn or person carried sensors, from different manufacturers, each with their own data format, communications exfil, and Windows application to view and make sense of perishable tactical data. The primary issue was the intense cognitive lift required of the commander who had to toggle between 18 Windows applications to make sense of what was going on during a mission that might last 40 minutes, span an operational area of no more than 200 meters, with decision windows measured in minutes.
The 18 information silos, each with different data formats, created a disjointed operational view that negatively impacted the speed of command. What was needed was an IoT fusion platform that would run on remote and far forward edge compute devices where sensor data could be processed locally, mashed into a single message, and shared securely amongst the team.
Blueforce provides a straightforward path to transform disparately formatted sensor data streams into a sensor grid that spans all domains of warfare, public safety, smart cities, and cyber-physical security. Blueforce core technology is a sensor fabric that provides universal access to sensor data from any authorized point on the network and an extensible middleware platform with each node forming a lightweight services bus with its reciprocal subscribers.
Core to the architecture are three primary operational drivers, each exposed as a set of services that are essential to meet the needs of time-constrained edge operations:
- Speed of Swarm: Rapid, secure, and self-forming human and sensor networks for a wide array of mobile and edge compute platforms which include humans, K9’s, unmanned systems, AI services, unattended ground sensors, and more.
- Horizontal Fusion: Distributed sense making of “swarm intelligence†across the team which is presented as processed information that is timely and relevant. This processed information tells a story of what is going on, but when combined with recognitional support, can convey “signatures†that denote deviations from expected mission outcomes.
- Agile and Rapid Extensibility: Field operations are fundamentally non-predictive. Blueforce enables rapid adaptation in the field by allowing the operator to enable and disable capabilities on the fly based on mission requirements. More importantly, open APIs and SDK allow rapid creation of Blueforce “plugins†which can be built and deployed in days providing a future-proof and sustainable platform for new edge IoT sensors and artificial intelligence capabilities as they become available over time.
What follows are the core components of the Blueforce Decentralized Fusion Engine, a patented stack that is native to all Blueforce products. It’s a three-layer “wedding cake†that enables the above-mentioned core operational drivers and is shown in the image above. Each of these layers is covered below.
Subscriber Layer
The Blueforce Subscriber layer provides a means to quickly enable rapid access to people, sensors, and services enabled by the Blueforce platform. It is built on a core premise of “need to know†enabling rapid access to other endpoints, but also allows the user to quickly revoke access. This same subscription interface is used for self-synchronization of processed location, sensor, and collaborative information between the user and other authorized endpoints. Publishing endpoints also distribute “viewers†via background processes to allow subscribers to view specific metadata, even though they do not possess the plug-in that created the data. The Subscription interface is exposed via a BlueforceID which looks like a standard email address (i.e. sgt.snuffy@army.mil). For more rapid subscription, QR codes can be enabled allowing users to merely point their Blueforce client at a shared QR code.
Decentralized Fusion Engine
The Blueforce Decentralized Fusion Engine (DFE) ingests structured, unstructured, and semi-structured data, fusing 1-n attributes from 1-n sensors with metadata, resulting in a serialized stream of expandable and collapsible messages, called Extended Presence (XPRES), a payload extension of Extensible Messaging and Presence Protocol (XMPP), which is fully compatible with the original Open Architecture messaging standard. Built on commercially available messaging software, this information distribution mechanism provides an efficient and sustainable means to interconnect disparate body-worn, proximate, and device embedded sensors and systems, supported in a distributed manner.
Real-time data is fed to the DFE via Blueforce “pluginsâ€, which transform sensor or device specific data formats into a normalized, device-agnostic, and network-agnostic XML message that represents single sensors, services, or combinations of multiple sensors and services. DFE generated XPRES messages can be shared horizontally and across echelons, while simultaneously utilized by applications on the local device and on remote systems. XPRES, the Blueforce extension of XMPP, is pliable and has been bridged to existing schemas, such as the Cursor-on-Target (CoT), REST/JSON, and the Army’s Integrated Sensor Architecture (ISA), which enables multiple systems to work together and share data across boundaries in a co-operative manner, easing access to previously hard-to-reach capabilities and easily bridging emerging schemas without significant impact to performance.
The DFE also houses “modules†which are also portable plugin-like containers which house core value-added services that can be applied across processed plugin data payloads. Modules are Blueforce proprietary (i.e., no API at this time) and are essentially a form of plugin that can be used to extend core functionality while providing API interfaces to any and all plugins. Examples include (but are not limited to):
- Multi-Variant Threat Detection Modules: A module that monitors sensors, meta-data, and behaviors on the local device, but can also look across all of the meta-data received from subscribed endpoints. While enabling advanced recognitional support of “meâ€, it also can proactively monitor and make sense of meta-data across and an entire team.
- Cryptographic Modules: Today Blueforce ships with a FIPS 140-2 certified cryptographic module, but expect to see new pluggable modules that can expose blockchain and other emerging algorithms.
- Machine Learning Modules: Logic that can monitor human behavior, reactions, and fused sensor meta data such that patterns and reactions to threat may be recognized and leveraged for ongoing recognitional support.
Plugin Layer
The Blueforce plugin layer enables agile and rapid extensibility via dynamically delivered software plugins that provide an interface to accommodate a continuously growing diversity of novel and legacy sensors, as well as AI and data gateways. For sensors and services that push data or expose an application programming interface (API), the systematic management of lightweight, reusable applets is much more sustainable than separate point integrations for each application. Automated software plugin upgrades enable algorithms to be fielded at speed and scale. Open application programming interfaces APIs to the DFE connect sensors, data, and services to devices and external application programs and dramatically streamline bringing the addition of new sensors and algorithms into the network. Moving from concept to capability can be as short as three (3) days. A Blueforce plugin provides four layers of edge processing:
- State Management: Maintains connectivity with the sensor and/or target system. Provides a “state†bit that alerts when connectivity is lost so that decision-makers are aware of the currency of metadata.
- Query and/or Listener: Logic that calls and/or listens for sensor data and/or target information services.
- Pre-processing and Business Logic: Processes sensor data and provides handoff to the in-memory queue.
- Inter-Process Messaging Bus: An API supported interface that allows plugins to talk to each other at bus speeds. This is an essential component for sensor cueing amongst dissimilar sensors and services running on a person or in a proximate environment.
- Cache and Release to DFE: In-memory pre-processed sensor data specific to a plugin is cached and waits for the DFE to “swing through†and pick up meta-data for bundling into XPRES.
Blueforce plugins are built and delivered by Blueforce, but also by the Blueforce ecosystem of service provider partners using our supported APIs and SDK. While much of the narrative here has been specific to sensors, Blueforce plugins are delivered to support a diverse range of cyber-physical sensors as well as information services. Specifically, a Blueforce plugin can provide normalized and rapidly subscribable access to:
- Sensors: Blueforce plugins are delivered to query and/or listen to body attached, proximate, and/or unattended sensors.
- Services: A Blueforce plugin can also be a fully self-contained information “service†such as a rules engine, AI algorithm, and/or a custom purpose-built service.
- Gateways: A Blueforce plugin can also be a bi-directional data gateway to transform and publish Blueforce XPRES data to/from a third-party and/or enterprise system. Examples include REST/JSON Publishers, US Army ISA, Cursor on Target, and AWS IoT (among others).
Blueforce will publish weekly blog posts starting next week that provide detail on a single plugin along with case studies for how each is used. If you have further questions, contact us at info@blueforcedev.com.