In 2004, Raytheon began to assess the future of weapon systems in a net-centric battlespace. Using internal funding, we studied Department of Defense (DoD) documents on the desired capabilities of the Net-Centric Environment (NCE) and what that might mean for expanded weapon-system roles. We have since developed a top-level operational concept for netted weapons and:
Built a reference architecture to describe how weapon systems could meet DoD's Net-Ready Key Performance Parameter for NCE interoperability
Developed some of the technologies resulting from that architecture
Proved their viability in lab demonstrations followed by a full weapon system prototype as described in this issue's article about Project NINJA (Netcentric INtelligence Jamming & Attack)
Understanding the full potential of net-enabled effectors requires some exposure to NCE-enabling features. The NCE vision is to provide an agile enterprise empowered by access to, and sharing of, timely and trusted information. The DoD is developing a technical understanding of how to accomplish this vision. Details are available from the office of the Assistant Secretary of Defense–Networks and Information Integration (ASD-NII) at www.defenselink.mil/cio-nii. Raytheon references include Technology Today's 2007 Issue 3, "C3I Systems: Critical Building Blocks to Delivering Net-Centric Solutions".
The NCE can be broken into a physical domain called the Global Information Grid (GIG) that includes many families of networks and processing systems, and an information-management domain generally viewed as a service-oriented architecture (SOA) foundation for many additional net-centric services. ASD-NII and the Defense Information Systems Agency have started multiple programs over the last four years to build an infrastructure to enable the evolution of the GIG and SOA-based information services.
The physical and information-management arenas must be combined to enable net-centricity; a common complaint among warfighters has been that net-centric capabilities didn't live up to expectations in overseas deployments because better networking just gave them more information they didn't need, overwhelming the operator. Those personnel, however, didn't have the NCE; they just had better networking and more bandwidth, resulting in more data — which isn't always a blessing. Information flows, interoperability and management must be addressed first, then the best physical network implementation can be chosen based on the information needs and data standards.
The Net-Ready KPP
To achieve its NCE Vision, the DoD needed a mechanism for evolving all warfighting system upgrades and new starts into interoperability with the net-centric infrastructure. This mechanism is called the Net-Ready Key Performance Parameter (KPP), established as a mandatory part of the Joint Capabilities Integration and Development System by the Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01E in May 2005. The Net-Ready KPP is enumerated in the subsequent CJCSI 6212.01D and can be studied through Web-based training such as the Defense Acquisition University (go to https://learn.dau.mil/html/clc/Clc.jsp and enter keyword "net-ready" to find class modules).
In short, the Net-Ready KPP guides development of an integrated architecture that describes how your system upgrade or new program will achieve compatibility with the NCE, enhancing system benefits due to leverage of the information-age infrastructure, and in return enriching NCE users' capabilities. The architecture must follow guidance from the Net-Centric Operations and Warfare Reference Model, including:
How your system will be exposed to authorized users as a service
Where your system requires support from certain core enterprise services
How all associated data types will be defined and provided following the net-centric data strategy
Which technical standards from a DoD library apply to those services/data types
The various views in the resulting architecture must show where your system links to key interface profiles, which are core networks and systems in the battlespace. They must also show the means the system will use to adhere to the DoD Information Assurance Certification and Accreditation Process, to ensure your system doesn't become a weak link in protecting the NCE from adversaries.
Once you have the architecture that describes your system interfaces, functions, and pertinent technical standards, you have established the system design requirements. As long as the physical hardware and software design can meet these logical requirements, the most cost-effective approach can be chosen to implement the net-ready system. Design effects on a net-enabled effector can be limited to just a few areas by focusing on the implications for a system at the tactical edge of military operations, rather than on worldwide networks and globally distributed enterprise services. Also note that Net-Ready KPP compliance will often be satisfied by implementing the architectural requirements in evolutionary phases.
The new system or upgrade should be designed to optimize exposure of potentially valuable data to the battlespace, and act to protect that information at the appropriate level given the risk of exposure. The system should provide accessible interfaces-link requirements, system software design, and inclusion of hooks for future growth, rather than settling for point designs.
The biggest paradigm shift faced by tactical-system designers is their new responsibility to meet certain needs that are outside the sensor, control node or weapon. Just as important as the tactical system design is the characterization of services it can provide, description of the data types used, and posting of those in the correct language to Internet-like registries. Key examples of these languages include Extensible Markup Language for data, and Web Services Description Language for services. This registration during system development, in a common form accessible to any authenticated user in the NCE, enables the warfighter with the greatest need during battlespace operations to access the best services to accomplish the desired objective.
The Netted-Weapon Architecture
To proceed from a general vision for creating net-centric-enabled weapons for the warfighter to actual development and demonstration, Raytheon built a reference architecture that flows the Net Ready requirement into guidance for weapon systems. We developed an operational level describing the potential capabilities of weapons in the NCE, then flowed that into implementation requirements to meet the Net Ready-KPP and enable those capabilities. Both levels are described below.
To describe possible operational capabilities for a netted weapon, our definition is "Weapons that are net-ready, acting as independent, versatile battlespace assets or as addressable elements of a control or launcher system with that capability." As we assessed NCE-enabling features, it became apparent that the big jump in capability comes from turning current dedicated-control, single-purpose weapons into flexible service providers limited only by the weapon's capabilities, and by policy restrictions such as doctrine and rules of engagement. The resulting potential operational capabilities are shown below.
Operational architecture provides the intended nodes or users of netted weapons, the information that must flow between those nodes, and the operational activities that expose the desired capabilities the system must have as a part of the net-centric battlespace. This operational architecture provides a "shopping list" to assess which capabilities make the most sense for a specific new weapon system or upgrade, backed up by the rigorous DoD architecture framework's set of artifacts that enable flow of the desired choices from that list into implementation requirements.
The logical level of the architecture, which translates from capabilities to design requirements, is where the Net-Ready KPP becomes reality. The operational activities are mapped to system functions that partition and implement the behavior of the system, but now they have additional service-oriented capabilities and technical standards to ensure a net-centric solution.
The operational information flows are mapped to system interfaces, which are also required to behave as service-based relationships and meet certain technical standards. All data types must be described at a logical level, enabling characterization to all other users meeting the appropriate technical standards. The Netted-Weapon Architecture addressed these requirements in a way that could guide any weapon system implementation, but it also resulted in something unexpected: We found a common method to meet many of those interface and functional requirements for all types of netted weapons.
The Netted Element Weapon Service™ (NEWS)
Architects can now leverage the DoD Architecture Framework Version 1.5, which provides explicit guidance on addressing net-centric needs through describing data types, following a service-oriented paradigm, and providing that information so other systems and users know how to access theirs. The original source of that approach, however, is the Net-Centric Operations and Warfare Reference Model, a component of the Net-Ready KPP. In seeking a path to map weapon systems to this model, it became clear that weapon systems — with inherently limited processing, data storage and bandwidth over available links — needed to behave as a service without the overhead associated with a full SOA implementation. We described the requirements for a service layer that could be implemented on weapon systems and provided the necessary functional and interface features. Raytheon has a patent pending on the NEWS logical design.
To obtain an idea of the need for NEWS, start with a commercial device such as a BlackBerry® or Windows® Mobile-based handheld PC. These have networked applications or interoperability layers that exploit the extensive power of the Internet and wireless networks, enabling data and e-mail access, service requests through Web interfaces, cell-phone calls, and a limited amount of data storage. Similarly, NEWS provides a service layer for weapon systems that enables any authenticated user in the Net-centric Environment to obtain and exchange translated data with the weapon best suited to meet a need, as shown in Figure 2.
The figure shows NEWS as a layer enabling the service relationship between embedded functions on the weapon system and all users and systems elsewhere in the NCE. As mentioned above in the development-phase requirements discussion, the weapon's available data types and services are posted in Internet-like registries long before the weapon is deployed. When brought into use, NEWS provides appropriate registration messages so the NCE can relate the operational asset to the registry entries, describing the services that system can provide and the data types used to perform the service agreements. NEWS will then follow with status data that might tailor the services available from that specific unit — for example, a sensor service may no longer be available if a seeker mode has failed — followed by specific data interactions when services are requested of the weapon system.
Figure 2 also shows examples of this service relationship, including:
The logistician interrogating any weapon to determine availability and suitability during planning
The targeter providing just the right weather and target intel to optimize automatic target recognition algorithms
The weapon providing data back to an authenticated tactical-edge control node to determine whether it can meet that user's needs
The key is that, within policy limitations set by human command, any user can access any weapon service, if it is possible within time and geographical constraints. A critical component missing from this description is labeled "NetFx Service Registry" in Figure 2. Between users on the broader NCE and the tactical-edge system, there must be a community of interest that leverages the SOA infrastructure by adding services specific to weapon system needs, such as ranking the best weapon for the right user at the right time.
The Netted-Effects (NetFx) Service
A common mistake in designing for net-centricity, or net-enabling a system, is to think that the only aspect that matters is choosing the system's physical data link. Beyond the fact that the information flows and service relationships must be determined before choosing the link solution, the deeper problem with this approach is that tactical-edge systems can't be net-enabled only by choosing a great data link. A binding relationship must be established between processor-hosted services and networks that help users choose the right service on the best edge asset. In addition, a service layer on the edge asset must enable information management over the right data terminal and network. The power of Raytheon's approach to net-enabled effectors is in the bound relationship between NEWS and NetFx Services.
Figure 3 diagrams NetFx functions. A warfighter or command-and-control (C2) node can submit a battlespace need and have that translated and routed into recommended netted-weapon services suggested by interfacing to NEWS on the weapon system. Flexible policy (doctrine) can then be set up to allow edge warfighters to request certain services from netted-weapon systems, with stringent information-assurance (IA) protocols.
Establishing the NetFx Services as a net-centric community allows a binding service from tactical users; through the foundational enterprise services in the NCE, on to NetFx to link the right user with the right weapon, and out to the weapon system through the best available link. Putting the right capabilities into the right layers of the NCE solves many critical issues, such as establishing connectivity between different domains and addressing IA over multiple layers. An example of the latter is shown in Figure 3.
Although IA is a critical issue that will require multiple advances to reach the NCE's full capability, it can be made more difficult than necessary if all the IA layers are lumped into one. Just as the NCE's flexibility is implemented through layers, IA is best addressed by putting the right protections in the right NCE layers. The SOA Foundation is addressing many enterprise-level IA concerns through authentication mechanisms for users, policy enforcement points that can evolve as battlespace needs evolve, guards allowing multiple levels of security, and encryption techniques where applicable. A community such as the NetFx Services must build in compatibility with the foundation's mechanisms, then add specific features such as authorization, which establishes whether a particular warfighter is allowed by policy to obtain certain netted-weapon services and under what conditions. A tactical-edge system with a service layer such as NEWS must build in compatibility with the relevant community, ensuring that only authenticated and authorized service requests are acted upon. It must also support the edge system's physical security features, such as hardware encryption.
When the NCE is combined with services — such as NetFx, an equivalent sensor-management service, C2 decision services, and net-enabled tactical-edge systems — then users have a powerful combat system that "synchronizes" the battlespace. Since the user's needs can be translated and routed to the best service provider, and the tactical-edge systems can respond in kind, the optimal method to execute an engagement chain (formerly called a kill chain) can be identified before the warfighter presses the execute button. This capability is much more powerful than shortening the time for a single component of the Find, Fix, Track, Target, Engage, and Assess chain. By contrast, the combat system always provides the best asset for the highest-priority need.
Note that in the NCE, the existence of NetFx Services in no way precludes the continued use of legacy planning and decision systems. A particular part of the military may need to continue using a C2 application that predated Web services and data registries. Although the application lacks full NCE benefits, it can have some interaction through special interfaces to enhance SOA compatibility.
In the last four years, Raytheon has developed this NCE vision, architectural concepts and select proof-of-concept technology demonstrations, but much work remains. The next article in this issue describes Raytheon Missile Systems' pilot program for validating the net-enabled effectors vision: a netted version of the Miniature Air-Launched Decoy (MALD), called Project NINJA, linked to airborne and ground-based nodes in a joint coalition military exercise.
