Close Advertisement


Tradeoffs Drive Distributed vs. Consolidated Architecture Choice

Today’s technology enables multiple functions to consolidate into one subsystem. But there are some cases are a distributed set of subsystems is preferred.


Keywords in this Article:

No Keywords

  • Page 1 of 1
    Bookmark and Share

Article Media


Thanks in large part to the ongoing miniaturization of technology, today's system designers have an increased ability to integrate more functionality into a single small-form factor subsystem chassis than ever before. This trend has been a boon for size, weight, power and cost (SWaP-C) constrained embedded solutions deployed in defense and aerospace applications. Over the last five years, the evolution of technology has delivered lower cost, smaller size and reduced power consumption. It's also made it far less burdensome to consolidate more functions into a single box that can be successfully cooled, built, and fielded.

On the surface, it might seem that easing the ability to get more functionality into a smaller footprint is an ideal pursuit for all embedded system designs. Perhaps counter-intuitively, there are clear cases where a distributed architectural approach, where multiple boxes are installed in different locations on a platform, is superior to a consolidated approach in which as many functions as possible are co-located in a single enclosure (Figure 1). While there's no single rule-of-thumb for all applications, a preferred system architecture can emerge after evaluating a number of design tradeoffs and considerations.

Figure 1
In a distributed approach multiple boxes are installed in different locations on a platform. In a consolidated approach as many functions as possible are co-located in a single enclosure.

Distributed LRU Strategy

At one time-before the semiconductor industry had successfully advanced component integration and power management to the level seen today-the norm was to architect a system solution with distributed line replaceable units (LRU). Simply put, technology couldn't support packing all the different desired functionality, such as mission processing, data networking and I/O communications, into a single small enclosure. What's more, a particular program requirement, or the customer's approach to fiscal budgeting and their supply chain may have encouraged the use of "single function" distributed solutions.

Some programs might not have had enough leeway to permit the inclusion of additional functionality beyond the defined functions of that LRU's specification. Even if there were SWaP-C benefits to be accrued by adding more functionality into an LRU, systemic purchasing constraints might have obviated their consideration. Often, the funds simply aren't available for something "out of scope".

Inefficient Redundancies

Historically, the US government approached system upgrades with a "bolt-on" tactic. This led to military platform upgrades comprised of any number of "stove-piped" narrow function devices that might not be interoperable with other equipment. These bolt-on boxes might have been added at different times to achieve different program objectives. The kludge-like result was often left to the system integrator, and ultimately the warfighter, to deal with. This led to undesired results such as limited cabin room for solider or weapons, along with antenna proliferation, since each unrelated new communication or navigation box might have its own GPS and antenna. The end result was all too often a non-SWaP-optimized architecture.

Today, technology is able to support ever smaller subsystem architectures, and new efforts, such as the US Army's VICTORY initiative, are helping to eliminate unnecessary redundancy, reduce SWaP burdens, and foster networking and interoperability on ground vehicles. While new technology might be capable of supporting a consolidated "all-in-one" solution, there are still many good reasons and strong cases for taking the distributed subsystem design route. The table in Figure 2 reviews the major factors in favor of a distributed system approach.

Figure 2
There are some good reasons and strong cases for taking the distributed system approach

Distributed vs. Consolidated

System integrators for once have a real choice between which of the two approaches they should take-distributed or consolidated. To help shed some light on the different types of scenarios in which one of these two architectures has a clear advantage, some real world examples follow.

Scenario #1: An aircraft platform has characteristics that encourage the placement of electronics in specific payload locations.

Goal: To minimize SWaP, while optimizing weight distribution of electronics and wiring harnesses.

Solution: Employ the smart distribution of LRUs and cabling on the platform to support aircraft operations.

A customer for an unmanned helicopter program had initially been buying a combined Ethernet router and switch LRU for their network backbone installed on the aircraft. Their rationale was that since they were very space-constrained, they wanted to fit as much functionality as possible into a single device. The customer performed a detailed analysis of the mass and weight of the aircraft's on-board devices and how the placement of these devices and their associated cabling weight impacted platform performance. As a result, the customer is now evaluating a change for their system architecture to integrate separate smaller switch and router LRUs and separate wiring harnesses, with consideration on their effect on the aircraft's center of gravity.

Conclusion: For weight sensitive platforms, a distributed architecture may enable optimized system placement.

Scenario #2: A system integrator faces supply management headaches due to multiple SKUs

Goal: Reduce logistics complexity.

Solution: A consolidated architecture enables system integrator to standardize on fewer multi-function systems, to simplify procurement, installation, and sparing.

A system integrator under contract with a foreign military service had to consider purchasing and maintaining half a dozen different subsystems for each of its reconnaissance aircraft. This customer was faced with daunting purchasing and maintenance concerns resulting from the use of multiple different boxes, the functionality of which ranged from simple to more complex. Some of these subsystems were primarily tasked with network routing or switching, others primarily supported the mission computer side, with some performing red/black separation of the networks.

Rather than source six different boxes, each with their unique SKU that would complicate procurement and installation, the customer came to the conclusion that, although slightly more costly as a single LRU, significant simplification of their system configuration and supply management chores could be achieved by simply purchasing these multi-function systems that provided a superset of desired functionality and could be tasked for particular purposes in the platform architecture.

Conclusion: Deploying multi-function systems on some platforms (versus different distributed LRUs) can potentially deliver more functionality than needed in some cases, yet greatly reduce supply chain management complexity.

Scenario #3: Ground vehicle requirement to leverage network backbone and PNT technologies

Goal: Identify the best architecture for implementing VICTORY network services and assured position navigation timing (PNT) solution without adding SWaP burden

Solution: A consolidated system enabling a SWaP-optimized PNT hub that combines network switch, processing, secure GPS, navigation, and miniaturized atomic clock.

The US Army is pursuing an assured precision navigation timing (A-PNT) initiative to enable warfighters to operate in GPS-denied environments, using technologies such as M-Code GPS receivers, chip scale atomic clocks (CSACs) and inertial navigation systems. One of the currently favored system architectures for deploying assured PNT is based on a IP networked architecture, where a PNT hub device can leverage Ethernet to distribute all navigation/position/timing information other networked devices on-board the platform.

Thanks to the miniaturization of technology, this PNT Hub device can today also have an integrated computer, embedded GPS and network switch to support a host of VICTORY services. When combined with integrated CSAC atomic clock and inertial measurement unit (IMUs), this design approach eliminates multiple redundant GPS and antennas, while providing assured PNT in a single box.

Conclusion: As new functions emerge, system integrators need to add them to their platform without having to pay a harsh penalty for increased SWaP. The "all-in-one" consolidated approach offers the best way to eliminate redundancy and weight while adding needed functionality.

Modular System Solutions

An example of a COTS product line that supports both distributed and consolidated architectures are the Parvus Dura small form factor subsystems that use a modular stackable design to optionally combine computer networking and processing. The multi-function DuraWORX 80-41 model combines a quad-core Intel Core i7-based x86 compatible mission processor and a Cisco IOS-managed secure network router into a single modular platform (Figure 3). It integrates the capabilities of the standalone DuraCOR 80-41 computer, DuraNET 30-2020 IOS switch, and DuraMAR 5915 router subsystems. Alternatively, the DuraDBH-672 Digital Beachhead provides low-power ARM-architecture processing and Layer 2 switching in a single box with options for pre-integrated atomic clock, embedded military GPS receiver, and IMU.

Figure 3
The multi-function DuraWORX 80-41 combines a quad-core Intel Core i7-based mission processor and a Cisco IOS-managed secure network router into a single modular platform.

The before-mentioned examples highlight just a few applications and the architecture best suited for a particular customer design challenge. The examples also show that the benefits of miniaturization (prominently SWaP reduction) don't always lead to favoring a system architecture consolidation as the single best option. Ultimately, a system integrator will need to determine which architecture is preferred by considering such factors as the size of their platform, electronics weight distribution, desired integrated technical capabilities, maintenance and supply chain constraints, redundancy, and information assurance, among others variables.

Curtiss-Wright Defense Solutions
Ashburn, VA.
(703) 779-7800.