Contractors look for higher levels of integration from COTS suppliers

Story

February 11, 2010

Steve Edwards

Curtiss-Wright

Today's military technology contractors are designing portable, generic applications that can easily and rapidly migrate from development to deployed environment. However, this paradigm requires a higher level of service and support from their chosen COTS vendors.

As COTS embedded computing products continue to evolve, they become more complex with levels of performance and functionality that often require specialized skills and knowledge to integrate most effectively as part of a prime contractor’s deliverable system. A typical system such as a vehicle, sensor, helicopter, or Unmanned Aerial Vehicle (UAV) will comprise many sub-systems with components and assemblies from many different suppliers. Such subsystems might vary from a mission computer to a multicomputing sensor processor, but all will require either the contractor or the original vendor to integrate, test, qualify, document, and maintain them. With increasing subsystem complexity, contractors are refocusing their technical skills on system-level technologies that will be of future value to their business rather than being, of necessity, embedded board-level computer subsystem integrators. These contractors are developing generic, portable applications that demonstrate a system’s capability to customers and can quickly and easily migrate from development to deployed environment. This requires a higher level of service and support from their chosen COTS vendors.

Open standards support portability

There are two complementary paths to portability that include making extensive use of open standards and abstraction (or middleware). The government and end users strongly support the use of open standards available across a broad spectrum of applications, ranging from graphics and imaging to communications and networking. Open standards also include operating systems, operating system components, and APIs; development environments; compilers; design tools; and math and graphics libraries. Hardware open standards including VPX (VITA 46) and VPX-REDI (VITA 48) are well established and now also supported by OpenVPX (VITA 65), which clarifies concepts of architecture and interoperability. Middleware is often more closely tied to a specific hardware product, or to a range of COTS vendors’ products, and industry standards such as Message Passing Interface (MPI) and Data Distribution Service (DDS) are gaining ground in this area. This middleware aims to create a common API allowing application modules to operate and communicate without reference to any hardware-specific details of the hosting embedded processors, fabrics, or networks.

Comprehensive and adaptable middleware forms an essential element of the subsystem integration effort, providing the integrator with a flexible model on which to base the communications design. This proves invaluable when, for example, concepts are taken from prototypes to representative hardware in the development laboratory and on to deployable hardware designed to meet all the project’s environmental conditions. Prototyping and the development laboratory stages might use dissimilar host processors, while migration to deployable hardware becomes an opportunity for technology refresh, or even a review of suppliers. However, using open standards and abstraction is no guarantee of performance on the selected COTS vendors’ products, making benchmarking or analysis-by-similarity essential steps in the process.

Performance specification

Some aspects of an integrated subsystem’s performance are relatively easy for a contractor to specify to the COTS supplier: environmental, cooling, power dissipation, power characteristics, Electro-Magnetic Compatibility (EMC), functional requirements, memory size, I/O requirements, and so on. But much more difficult to specify is how the subsystem will perform when running the contractor’s application and how the COTS vendor will prove the requirement is met. This becomes a joint responsibility, with the specification being developed as prototyping and testing proceed on the contractor’s application. Once a configuration is established, it must be monitored for the impact of a COTS vendor’s natural product line evolution, whether hardware, firmware, operating system, libraries, or drivers. Support for the same open standards must be maintained, and APIs to middleware or other embedded code such as system Built-in-Test (BIT) must have minimal future impact.

Integration of a subsystem requires more than the prerequisite range of services to configure, test, environmentally qualify, and document a set of COTS modules in a chassis. Experienced COTS vendors such as Curtiss-Wright Controls Embedded Computing (CWCEC) are able to offer complete, coherent solutions meeting customers’ and end-users’ objectives for use of open standards, portability, and longevity. Figure 1 illustrates an application-ready, VITA 46/48-based packaged subsystem for use in a ground-based radar application.

Figure 1: Open standards COTS systems are deployed in a wide range of applications, such as a ground-based radar system.

(Click graphic to zoom by 1.2x)

Many contractors are looking for COTS vendors to provide ways to ease their integration headaches and ensure a level of continuity into the future. The growing complexity and capability of embedded computing products, based on standards such as VPX, will require COTS vendors to step up to the next level of subsystem integration: They must have the right products, services, middleware, and tools to assist in the rapid transition from concept to deployment.

To learn more, e-mail Steve at [email protected].