2.1

Architecture Overview

A system architecture for an aircraft and weapon can be depicted as in Figure 1 below. A weapon system, consisting of a sensor, aperture, processor, payload, propulsion, and actuators must physically and logically connect to the aircraft to make up a system of systems. In this case, the suspension and release equipment provide for the physical connection and the stores management system provides for the logical connection.

Figure 1.

System Architecture for Aircraft / Weapon

2.2

Incorporating a Modular Open System Architecture

A Modular Open System Architecture (MOSA) can enable future “plug-and-play” weapons systems. MOSA provides the standards and infrastructure for the capability. The vision for a plug-n-play weapon system incorporates several features:

MOSA provides the common interface and the ability to self configure and self recognize, essentially automating tasks that are done manually or semi-manually (one platform at a time) in current systems. This is shown in Figure 2.

Figure 2.

System Architecture and the Stores Management System

2.3

Protecting Intellectual Property Within a MOSA

One major concern in dealing with MOSA is the notion that an open system removes the ability for businesses to maintain their competitive edge and that their intellectual property will be given away to others. The change to an open system is better characterized as defining the interfaces, not the activity inside the functional components within the system. In an open system, the interfaces must meet the standards – as shown with the green arrows in the diagram below, but inside the “box” you could have either a proprietary or non-proprietary component, depending on what fills the need the best. Pictured in Figure 3 below, is a random division of functions that can all work together because of the open interface, but that could be either proprietary or non-proprietary

Figure 3.

System Architecture and Proprietary / Non-Proprietary Functions

Through a MOSA approach, interchangeability, reduced non-recurring engineering (NRE), and other benefits can be realized without eliminating the intellectual property inside the individual components. This protects the competitive edge and incentives to innovate that are important for business and Government.

2.4

Functional Decomposition

Functional decomposition is a method for determining logical separation of functions into groups of physical modules. Careful functional decomposition reduces coupling between modules, and enhance the flexibility of the overall system, as illustrated in Figure 4. For Flexible Weapons, the architecture under development will look at logical functional and physical boundaries to separate the modules. A notional architecture, illustrated in Figure 5, shows how modules can be organized to enable the desired composability of the system. Various interchangeable modules are available to compose a system with the needed seeker, guidance, effect, and aerodynamics for a particular mission type.

Figure 4.

Functional Decomposition Provides a Way to Define Physical Modules Whereby Coupling is Minimized and Modularity is Maximized

Figure 5.

Flexible Weapon Notional Functional Decomposition

2.5

Architecture Development Plan

In order to successfully develop an open system design for weapons, an iterative, two-cycle approach will be applied. The first cycle will include the first revision of architecture development, while demonstrating modularity with bench-top hardware and preliminary software. The second cycle matures the architecture while implementing the first revision in the second demonstration. This two-cycle approach is shown graphically in Figure 6 below.

Figure 6.

Flexible Weapon’s Two-Cycle Development Plan

The first demonstration provides lessons learned early enough to feed into the architecture development, and builds momentum, while the second architecture provides a reference implementation and demonstration of the architecture with more flight-like components in preparation for transitioning to the next phase.

3.1

Software Development and MOSA

In following a MOSA approach, AFRL is building on the billions of dollars spent by the computer and networking industry that has already matured the architecture and the tools. AFRL can adopt methods for software development, data transfer, and open interfaces from the best proven practices of industries that already are familiar with this approach, such as PCs, cell phones, etc. This implementation does not result in scraping all the software we’ve already built, only changing how it works together and with the hardware so that we improve the reusability and build on a common infrastructure.

One of the improvements in the software architecture comes from using middleware. Having the middleware in the software stack decouples the software applications (algorithms, controls, etc.) from the hardware, as illustrated in Figure 8. That means the software is more portable (can be used on different hardware) and doesn’t have to change every time the hardware is changed. Reuse of existing software allows more experience with individual code (find bugs, know how it works & reduce learning curve), reducing risk, as well as reducing testing time and costs (because the software changes less frequently).

Figure 8.

Smarter Software Architecture Improves Software Reuse

3.2

MOSA Improves Software Reusability

We often say that roughly 80% of software is reused from one program to another. Unfortunately, that typically means that 80% of each software component is reused, while the remaining 20% requires changes to adapt to new hardware. In the old paradigm, introducing new hardware for a new mission means the interfaces between hardware and software changes (they are usually hard-coded, at least to some extent). This is costly in recreating the hardware/software interface – this is like creating Facebook and then rebuilding the internet and rewriting a web browser just to access it. Businesses have figured out how to use the existing infrastructure on the internet and web browsers to eliminate the interface problems.

The industry is very good at developing software the traditional way but there is a better way that will further reduce the cost of software. Software is often the highest technical risk area and by reducing the amount of software that is written for each system, the risk is reduced. With software reuse, there is a reduction in both the non-recurring engineering (NRE) and the testing costs.

Figure 9.

Software Reuse Saves Time and Money

3.3

Packetized Data Transfer Improves Modularity

Packetized data transfer is one way to modularize the data path, and when coupled with encapsulation, significantly simplifies how we handle data. This is the way terrestrial data networks work – like sending email from a smart phone, a desktop machine, or a web browser: each system can send data across different kinds of networks and still work seamlessly with each other.

Figure 10 illustrates how packetized data transfer enables a modular data path.

Figure 10.

Packet Encapsulation

As a first example of a packetized data path, the data packet, “A” is generated from the source, or “Sender”, is encapsulated when transferred from the internal network (“v” to “w”) to the first external network piece (going from “w” to “x”). When transferred to the next external network piece (“x” to “y”) there is a different protocol and packet type, but “A” is just encapsulated in the new type (“B”). Upon reaching the destination it is delivered as “A”, just like when it was generated.

In a second example you can see the modularity: if you change the source packet type from “A” to “D”, the rest of the network can remain the same and still get the data where it needs to go.

In a third example, changing the packet type for the “w” to “x” network from “C” to “E” type packets, the encapsulated “D” packet doesn’t have to change at all. It just works.

The architecture minimizes change propagation and maximizes compatibility – which is why the internet works this way, too.

The basic architecture shown in the previous illustration may look more familiar if you look at a container transportation system, illustrated in Figure 11 below. They are the same basic architecture.

Figure 11.

Packet Movement Through the System

Packaging bits into sub frames and frames, then creating packets out of them is like putting books (data) into boxes (sub frames) and boxes into pallets (frames) then pallets into a container (packet).

Once packetized, the method for delivery can be varied from trucks, to cranes, to boats, to trains, and the same packet just rides along whatever the method. It can then be unpacked at the end and is still the same data.

To show the modularity, which allows upgradability or variability, imagine the ship is obsolete and is replaced by a containerized aircraft. The transportation process doesn’t change, and the packets don’t change. The books don’t care if they are transported via boat or plane, they just get where they need to go.

Once the system is put together, the end user doesn’t need to understand the complexities of the system. It just works.

3.4

MOSA Can Provide Additional Benefits

Figure 12 illustrates several additional benefits and characteristics of a MOSA-based system.

Figure 12.

MOSA-Based System

In the left side of the figure, you can see that the MOSA portions of the system can work with heritage components (actual hardware, or networks, or other software) as long as the heritage interface (red line) is provided by the MOSA components. This flexibility is helpful in rolling a new architecture into an existing system.

Other added functionality, shown on the right side of Figure 12, is also possible in a MOSA system. In this case, the link between A and B is replaced by software applications that look like A and B, but enable splitting out A’s interactions into multiple B units, or adding a logging function to the network traffic.