Filling the gaps in COTS subsystem integrationStory
April 02, 2007
As the digital battlefield takes shape, it is becoming ever more difficult to define the boundaries and requirements for embedded computing systems.
As the digital battlefield takes shape, it is becoming ever more difficult to define the boundaries and requirements for embedded computing systems. Platforms such as combat aircraft, helicopters, or UAVs – which themselves may contain many tens of subsystems – are required to perform their missions cooperatively with any other types of platforms, adding to overall complexity. COTS suppliers must step up to understand the broader issues of how their products will be used if they are to offer integrated subsystems to their customers.
The RQ-8 Fire Scout UAV, which Northrop Grumman supplies to the Navy, is a good example of such a complex system. The Fire Scout was designed for Vertical Take Off and Landing (VTOL) operation from the helicopter deck of a warship and can carry out much of its mission semiautonomously. Designed initially as an aerial surveillance platform with streaming video feed to the surface, Fire Scout, illustrated in Figure 1, has continued to evolve to accommodate multiple sensor types plus air-to-ground weapons, becoming the RQ-8B. It has now been selected as the Class IV-A brigade-level UAV for the Army’s Future Combat System (FCS).
As platforms such as Fire Scout evolve, they take onboard more embedded computing capability. These platforms would typically take the form of enhanced flight management systems,
multisensor payload interface subsystems, and enhanced intra-platform networking based on Ethernet or switched fabric technologies. To reduce project costs and time-to-deployment, subsystems such as these are based on COTS modules and software, which also enables rapid prototype assembly and earlier integration. To consolidate these benefits and capitalize on their extensive product knowledge, COTS suppliers may be tempted to offer integrated, application-ready subsystems for this class of project without a deep enough appreciation of the complexities involved.
Successful COTS subsystem specifications will include these application-level requirements:
- Multilevel I/O and networking interoperability – physical, electrical, protocol performance and response, and driver requirements
- Processor performance, memory capacity, and bandwidth available for the user’s application above RTOS, drivers, and middleware
- Response of processor/RTOS combination to external stimuli
- Critical algorithmic performance parameters
To many, a COTS subsystem would be adequately described by its I/O ports, memory size, memory bandwidth, procesor performance, and support for an off-the-shelf RTOS. However, these are only a fraction of the parameters that might need to be specified to fit a new subsystem into the aforementioned UAV example. Interoperability among the new subsystem’s individual components should be a given, but how should subsystem interoperability with the remainder of the existing platform be defined? A supplier’s I/O device driver might be optimized for interrupt-driven operation only, yet the subsystem might have real-time response or determinism requirements that preclude using interrupts. Another example may be the performance of an IP stack that adversely affects communications between already tested and proven subsystems within the platform. These types of issues require more than a tick in the box during the selection process.
To be succesful in the subsystem integration business, COTS vendors must invest in ways to better understand their customers’ needs. It will be necessary to develop domain expertise – people with application knowledge of control laws, radar, sonar, graphics, safety criticality, determinism, networking, and communications, as well as the traditional specialist product knowledge. It will be necessary to offer advice and preempt potential problem areas with workarounds or modifications to standard products. Very often, the solution will be to offer alternative configurations to overcome potential performance shortcomings. The ideal is to offer proof through benchmarking or prototyping in a representative platform environment before the configuration is cast in stone.
Figure 3: rugged RES-110 Ethernet switch
Figures 2 and 3 illustrate equipment based on COTS integrated subsystems from GE Fanuc that have been successfully deployed on UAV platforms, including Fire Scout. These are fully enclosed with their own power supplies and have been qualified to meet the requirements of MIL-STD-810. Figure 2 shows a 3U CompactPCI mission computer. The rugged RES-110 Ethernet switch illustrated in Figure 3 is designed as an intraplatform managed Layers 2 and 3 GbE switch. Based on off-the-shelf subsystems, the final configurations of these subsystems as delivered to the customer demonstrate the value of open dialog during the selection and prototyping phases of project development.
Even 12 years from the introduction of COTS as mandated procurement policy, there are still best practices to be explored and lessons to be learned, particularly in the case of subsystem integration. The rapid pace of technology growth that has transformed the war fighting capability of today’s military systems may have created a requirements analysis gap in its wake that only COTS suppliers themselves can fill. Recent industry consolidations now give the major players the muscle to successfully fill this gap and realize the market potential of integrating COTS subsystems. The solutions are likely to be found in the right blend of domain experts, benchmarking, performance specification in application-like environments, and new, layered interoperability models that could become part of a common equipment specification language. This can only help fuel greater COTS adoption and close the gap between contractors’ and suppliers’ needs and expectations.
To learn more, e-mail Duncan at [email protected].