Blog
Why NGC2 Starts at the Edge
The Army’s challenge is not a lack of data. It is getting the right data to the right commander, in a usable format, at the time and place it is needed.
Currently, operational data can be confined within distinct warfighting systems, documented by hand, or transferred through intricate workflows that necessitate users to extract, interpret, and rearrange information before it can aid in decision-making.
Next Generation Command and Control, or NGC2, is designed to change that.
NGC2 is the Army’s clean-sheet framework for moving, organizing, sharing, and using operational data.
Instead of continuing to build separate systems for fires, intelligence, logistics, communications, and other functions, NGC2 brings them together through a common technology stack.
Supporting that stack requires tactical edge computing. Commanders need computing power, networking, storage, and application access wherever the mission takes them—whether operating from a vehicle, a building, a dispersed command post, or a concealed field position.
That creates a growing requirement for rugged, modular, and scalable edge infrastructure.
NGC2 is not one application, command post, or piece of hardware. It is a framework connecting the technologies required to ingest, move, organize, store, and act on operational data.
The Army describes NGC2 as a four-layer technology stack:
Each layer serves a different purpose, but all four must work together to provide commanders with timely, relevant information.
This approach differs from traditional command and control systems, which were often developed as separate, function-specific platforms with their own hardware, data formats, and operating environments. NGC2 moves away from those stovepipes toward a more connected and adaptable architecture.
The transport layer moves data across the battlefield. It includes the radios, satellite communications, private cellular networks, tactical data links, and other technologies used to connect formations over distance and terrain.
The goal is not to depend on a single method of communication. Commanders need several transport options so they can make threat-informed decisions about how data moves during each phase of an operation.
The transport layer provides the pathways, but the information still must be processed and organized before it becomes useful.
The integration layer helps manage the large volume of information generated and consumed by a military formation.
Displaying several data feeds on the same screen does not mean they are truly integrated. The information may still reside in separate databases, use incompatible formats, or require extensive manual processing.
The NGC2 integration layer uses artificial intelligence and machine learning to triage, organize, verify, and prioritize data. Its purpose is to make sure information reaches commanders while it is still relevant to the mission.
Instead of forcing users to search through disconnected systems, this layer helps curate the information needed for the decision at hand.
The data layer creates a shared and accessible operational data environment.
In traditional architectures, information often remains trapped inside the system that created it. Intelligence, fires, logistics, and other functions may each operate from separate versions of operational data.
NGC2 is intended to make information available across warfighting functions. A location identified by an intelligence application can also inform fires planning. That activity can then update logistics tools as ammunition, fuel, and resupply requirements change.
A coherent data layer supports synchronized decisions, reduces duplicate processing, and gives both users and AI-enabled applications access to more useful information.
The application layer is where commanders and Soldiers interact with the data.
Instead of relying on a dedicated hardware box for every function, NGC2 delivers capabilities through software applications that can operate across command-post workstations, tactical vehicles, laptops, handheld devices, and other interfaces.
Applications can be tailored to the mission and updated independently from the underlying hardware. Some may be Army-wide, while others may be developed by individual units to address specific needs.
This approach reduces dependence on proprietary systems while supporting faster updates and continued innovation.
The NGC2 stack depends on infrastructure that can operate close to commanders, sensors, operators, and platforms.
Modern transport technologies can move more data than before, but battlefield communications will still be congested, intermittent, degraded, or contested. Critical processing cannot always wait for data to travel to a distant cloud environment or centralized data center.
Tactical edge computing allows units to process and store information locally. This can help them:
The edge is not one fixed location. It may exist inside a combat vehicle, at a mobile command post, aboard an autonomous platform, or across a dispersed formation.
The supporting infrastructure must be able to move with the mission.
The Army’s NGC2 approach moves away from the assumption that command and control must rely on a large, preconfigured command post or fixed collection of systems.
Instead, the Army is exploring modular building blocks that commanders can arrange around the mission and threat environment.
A command post may need to operate from a vehicle, occupy an existing building, disperse across several positions, or rapidly displace and reassemble. Computing, networking, and storage resources must therefore be capable of being separated, recombined, and expanded without redesigning the entire system.
Modularity is not simply a product feature. It is an operational requirement.
A stackable architecture provides a practical way to build these modular NGC2 environments.
Rather than deploying one oversized server or a collection of unrelated appliances, stackable systems combine purpose-built nodes into a mission-specific configuration.
A deployment may begin with rugged mission compute. GPU acceleration, tactical networking, additional storage, or other capabilities can then be added as requirements evolve.
This enables organizations to build the capability required for a particular mission without carrying unnecessary hardware.
Mission-Specific Configuration
Different formations require different resources. A sensor-processing mission may prioritize GPU acceleration and storage, while a command post may need greater application-hosting capacity and network connectivity.
Stackable systems allow planners to assemble the right combination of capabilities for each deployment.
Faster Reconfiguration
Operational requirements change quickly. A modular stack can be expanded, reduced, or reorganized without replacing the entire computing environment.
This supports experimentation, technology insertion, and changing mission demands.
Reduced Integration Complexity
A common family of nodes can reduce unique cabling, mounting hardware, software integration, and sustainment requirements.
Common building blocks can also simplify training, maintenance, sparing, and lifecycle planning.
Size, Weight, and Power (SWaP) remain major constraints for tactical systems.
A stackable architecture helps units avoid carrying excess capability. They can deploy the compute, networking, and acceleration resources needed for the mission without defaulting to a much larger fixed system.
Tactical Networking for the Transport Layer
The transport layer connects formations across the battlefield, but data must also move between systems within the local tactical environment.
Rugged network switching connects compute nodes, radios, sensors, storage, workstations, and vehicle systems. Within a stackable architecture, networking becomes part of the same mission-configurable infrastructure as compute and storage.
Edge AI for the Integration Layer
The integration layer must triage, verify, and prioritize large amounts of operational information.
GPU-enabled edge nodes can support computer vision, object detection, sensor fusion, pattern recognition, AI inference, and operational modeling. Processing these workloads locally reduces the need to send every raw data feed across a constrained network.
Instead, the edge system can analyze information and forward the most useful outputs.
Distributed Compute for the Data Layer
A shared operational data environment requires compute and storage resources that remain available across the formation.
Rugged edge servers can host local databases, virtual machines, containers, mission applications, data integration tools, and synchronization services. Local processing allows important information and applications to remain accessible even when connectivity to higher echelons is interrupted.
Flexible Mission Compute for the Application Layer
NGC2 applications require a computing foundation that can support changing software requirements.
Flexible mission-computing nodes can host multiple applications while allowing software to be updated independently from the hardware. This supports virtualization, containerized workloads, rapid testing, and software-defined capabilities without requiring a dedicated appliance for every application.
The ATMOS2 Series is designed around the modular-building-block approach increasingly required at the tactical edge.
Rather than treating mission compute, GPU acceleration, and networking as completely separate systems, ATMOS nodes can be combined into a compact, stackable architecture.
An ATMOS deployment may include:
The objective is not to prescribe the same configuration for every unit. It is to provide common rugged building blocks that can be assembled around the workload, echelon, platform, and threat environment.
The ATMOS2 GPU brings high-performance GPU processing to the tactical edge.
Within an NGC2 architecture, it can support AI inference, computer vision, sensor fusion, video analytics, data classification, autonomous processing, and decision-support applications.
Local GPU processing allows more analysis to happen near the data source. This reduces the need to transmit large volumes of raw information across constrained networks and helps accelerate the movement from collection to insight.
The ATMOS2 CDS provides rugged computing resources for mission applications, virtualization, local data services, and distributed processing.
Its seven physically independent Ethernet controllers give system integrators greater flexibility when working across separate networks, sensors, data paths, or mission functions.
The ATMOS2 CDS can support command-post computing, vehicle-based mission systems, local application hosting, virtualized workloads, and architectures requiring multiple distinct network connections.
The ATMOS2 Switch supports local data movement between compute nodes, radios, sensors, storage systems, operator interfaces, and other mission equipment.
It provides the managed tactical networking needed to connect the individual components of the edge environment and helps support communication between the transport, integration, data, and application layers.
The true value of the ATMOS Series lies in its ability to integrate nodes into a stack tailored for specific missions…
For instance, an AI-driven sensor-processing setup could combine the ATMOS2 GPU with the ATMOS2 CDS and ATMOS2 Switch. In contrast, a mobile command post might focus on the CDS and Switch, incorporating GPU capabilities when sophisticated analytics are necessary.
A multi-network deployment can use the CDS and its independent Ethernet controllers to support separate connections, while an autonomous platform may emphasize compact GPU processing and onboard mission compute.
The configuration can change while the underlying platform architecture remains consistent.
Future command posts must be able to move, disperse, and reassemble quickly.
Large, static systems can be difficult to conceal, protect, and relocate. Modular infrastructure allows computing capability to be distributed across smaller footprints, installed in vehicles, positioned inside temporary structures, or separated across multiple locations.
A stackable architecture supports a more mobile and survivable command-post model while preserving access to operational data and mission applications.
Technology will not replace a commander’s judgment.
The purpose of NGC2 is to reduce the time and effort required to find, move, translate, and organize information so commanders and staffs can focus on decisions.
That means providing relevant data instead of unnecessary volume, shared information instead of conflicting system outputs, tailored applications instead of rigid hardware stovepipes, and local processing instead of complete dependence on remote infrastructure.
When the architecture works as intended, Soldiers spend less time making the network function and more time understanding the situation and acting on it.
NGC2 represents a shift from separate warfighting systems toward an integrated technology stack centered on operational data.
Delivering that architecture at the tactical edge requires more than increased bandwidth. It requires rugged compute, GPU acceleration, local storage, tactical networking, and flexible application hosting at multiple echelons.
It also requires modular building blocks that can move with the formation and adapt to changing platforms, threats, and mission requirements.
The ATMOS Series provides one approach to building that foundation. By combining stackable compute, GPU, and networking nodes, organizations can create scalable edge environments that support the transport, integration, data, and application layers of modern command and control.
The result is not simply more computing power at the edge. It is a more adaptable infrastructure designed to place useful data back in the hands of the commander.
