“A&D Requirements:
- Applications: C4I, tactical systems, weapons systems, radar, display, shipboard systems
- Mission critical
- Size, weight, and power issues
- Infrastructure consolidation
- Development, risk, and cost reduction
- Rapid technology refresh and insertion
- Focus on mission, not maintenance”
The requirements list above forms the basis for many military RFQs, and VME would be an obvious choice for really rugged platforms, whether air- or conduction-cooled. As well, VME’s heritage and proven track record might seal the deal for many modular applications.
But grab the tomatoes, fire up the blogs, and ready the retorts. The title of this column does not refer to VME. I’m specifically referencing PICMG’s Advanced Telecom Computing Architecture (AdvancedTCA), AdvancedTCA’s related form factors including Advanced Mezzanine Card (AMC), and the Service Availability Forum’s (SA Forum’s) middleware specs1. What the heck am I doing writing about these in a magazine dedicated to VME? Surely I’ve lost my mind, or have been “bought off by the opposition.”2 In fact, telecom-related specs have influenced VITA documents many times, including VITA 31.1 (PICMG’s 2.16 Ethernet packet switching technology), VITA 38 (system management on VME), and VITA 42 (XMC mezzanine with IPMI capabilities), to name a few.
As well, a notable percentage of the vendors building VME boards and systems also build PICMG-related gear. GE Fanuc, Emerson Network Power (who purchased VME’s originator, Motorola), and Curtiss-Wright Controls Embedded Computing (CWCEC) come immediately to mind, but there are many others. Both CWCEC and GE Fanuc have secured military program wins using 3U CompactPCI or AMC LRUs. While PICMG industry experts agree that CompactPCI – also known as “PICMG 2.x” – wasn’t terribly successful, AdvancedTCA (“PICMG 3.x”) is gaining traction in telecom markets. A report by Venture Develop-ment Corporation, the very same VDC that members quote when crowing about the VME market, predicts AdvancedTCA to grow to $7.0B by 2012. More conservative estimates put the AdvancedTCA market down around $1.2B by then.
Most importantly, VPX Gen 2 – the marriage of the OpenVPX Working Group’s efforts and the future VITA 65 – was hugely influenced by PICMG’s high-availability characteristics, fault tolerance, and shelf management. Documentation provided by OpenVPX originator Mercury Computer Systems uses telecom nomenclature to describe OpenVPX’s notional system architecture in planes: utility, management, control, data, expansion, and user I/O. The OpenVPX charter explicitly states a goal to “control and manage the assignment f VPX pins to functional planes in an interoperable architecture” (see Figure 1).
Figure 1: The OpenVPX Working Group is creating a system specification for what I call VPX Gen 2, tying the numerous VITA 46 dot specs into an interoperable and telecom-inspired high-availability system. Note the planes architecture.
It’s clear that the 14+ OpenVPX member companies (as of April 22) intend for VPX Gen 2 to follow the telecom control/data/management plane methodology, if only as a way to guarantee High Availability (HA) and quick interoperability. The existing VITA 46 dot specs are a proliferation of individual specs that need to be cohesively tied together by an overarching systems document in order to build future VPX-based VME systems. In fact, every person I’ve interviewed about VPX Gen 2 has stated that it is essential to stop the proliferation of the inherently stovepiped dot specs by creating a systems document through the OpenVPX Working Group.
There is no question that the ultimate document will draw heavily from PICMG’s AdvancedTCA specifications, including the IPMI shelf management software (just ask Pigeon Point, an OpenVPX member). As well, other open standards like Carrier Grade Linux and the SA Forum’s rigorous hardware-to-middleware-to-application software layered interfaces most likely will provide inspiration. In SA Forum parlance, the middleware sandwich provides an Availability Management Framework, Platform Management, Security, Messaging and Notification, Cluster Membership, and other HA services. Most importantly, the APIs are designed to guarantee multivendor hardware and software interoperability and high-availability capabilities at the system level.
But while fighter aircraft, NRO reconnaissance satellites, and JDAMs are what we think of when hard-core military applications are discussed, the fact remains that shipboard, command and control (C4ISR), and information systems are mostly based upon civilian networks, servers, and PC technology. That puts specs such as PICMG’s AdvancedTCA and the SA Forum’s high-availability middleware smack in the sweet spot for many A&D systems. RadiSys, GoAhead, and other AdvancedTCA vendors cite numerous program wins for their gear in mostly benign communications and C4I programs such as Lockheed Martin’s Aegis shipboard dual-redundant/fault-tolerant weapons system. Prime contractor BAE is also pushing really hard to create rugged versions of AMCs in a spec called Rugged MicroTCA.
So do I think that AdvancedTCA, AMC, MicroTCA, Carrier Grade Linux, SA Forum interfaces, and other telecom-inspired standards are going to encroach on VME’s rugged hegemony? Not a damn chance. VME, VPX Gen 1, and soon VPX Gen 2 are and will continue to be the clear leaders for rugged deployed military and mission-critical systems. AdvancedTCA and SA Forum vendors freely admit that their products are commodity-oriented, while VME and VPX are designed for inherently purpose-built A&D platforms with plenty of custom legacy code and hardware interfaces. Yet it’s certain that past and future versions of VME’s roadmap will continue to apply the best bits from other mission-critical and high-availability standards – including those conceived in the communications markets.
1 Hardware Platform Interface (HPI) and Application Interface Specification (AIS).
2 Full disclosure: I just moderated an E-cast with this article’s same title (sponsors were GoAhead Software and RadiSys). You can find the one-hour