Transcription

APPLYING SPACEVPX MODULAR OPEN SYSTEMS INTERCONNECTCONCEPTSH. Scott Goedeke, Northrop Grumman Electronic Systems, Baltimore, MarylandCharles Patrick Collier, Space Communications Program, AFRL/RVSV, Kirtland AFB, New MexicoAbstractThe VITA-78 SpaceVPX System Specificationrecently passed American National StandardsInstitute (ANSI) ballot and is now ready for wideadoption as the MOSA standard for space systems. Itinherits the VPX/OpenVPX pedigree and adds singlepoint fault tolerant features ideal for spaceapplications. These features work well for 6U sizemodules, but the same approach results in nsequently, the VITA 78Working Group spun off the VITA 78.1,SpaceVPXLite draft standard this year to addressthese limitations for 3U modules. This paper aims toaccelerate adoption of these standards by describingpractical concepts for 3U module implementationsusing the new SpaceVPXLite approach. The initialwork in this area focuses on interconnects forapplications needing minimal size, weight, power andcost.BackgroundThe ANSI/VITA 78-2015 [1] SpaceVPX SystemSpecification was produced by the VME (VersaModule-Eurocard) International Trade Association(VITA) 78 Working Group. This working group wasinitiated as part of the Government-Industrycollaborative Next Generation Space InterconnectStandard (NGSIS) [2]. The VITA 78 standard hassimilar structure as the ANSI/VITA 65-2010 [R2012]OpenVPXTM System Specification [3]. OpenVPXrapidly gained broad adoption for avionics systemsafter its introduction in 2010. It is based on the VPXstandard (Versatile Performance Switching) which isdefined by ANSI/VITA 46.0-2007 [4]. The VITA 65OpenVPX Working Group applied system level rulesand topologies using the VPX standard infrastructureto create a VPX based system specification. TheVITA 78 SpaceVPX Working Group used a similarmethodology to produce a system specificationintended for space applications. Figure 1, shows thecovers of the VPX, OpenVPX and SpaceVPXstandards and the dates when they became ANSIapproved. The VME International Trade Association(VITA) makes all of these standards available ontheir website.Figure 1. VPX Progressively Moved OpenHardware Architectures from Avionics to SpaceIntroductionThose familiar with OpenVPX will see a lot ofsimilarity to SpaceVPX with the exception of theSpace Utility Management Module commonlyreferred to as the SpaceUM. Another more subtledifference occurs in the concept of a “Controller”module. In OpenVPX, a “system controller” is apayload module capable of driving utility signalsREF CLK , SYSRESET* and NVMRO.InSpaceVPX, this extends to new utility signalsREF CLK1 , REF CLK2 (6U modules only) andthe system management pins SM(3:0). Anotherchange for SpaceVPX defines SM(3:2) as(SM STAT*, SM RESET*) for a more reliable I2Csystem management interface. Unlike OpenVPX,SpaceVPX System Controllers have their own slotand module profiles. System Controller profilesprovide up to four sets of utility signals to interfacewith up to four SpaceUMs. In 6U form factor, eachSpaceUM provides utility signals and powerswitching to up to eight payload modules yielding atotal extensibility to 32 payload modules. However,U.S. Government work not protected by U.S. copyright8A1-1

in 3U, a SpaceUM provides utility signals to no morethan two payload modules. As a result, in 3U,SpaceVPX systems extend out to only six payloadmodules, with two System Controller modules andfour SpaceUM modules, as shown in Figure 2. Thelimitation for small 3U systems led to the start of theVITA 78.1 SpaceVPXLite working group. Thispaper shows the progress to date on this standard,explains its goals and describes some of themethodology behind it. Further information on VPX,OpenVPX and the SpaceVPX standard can be foundat www.vita.com. VITA members also have accessto the VITA 78.1 SpaceVPXLite Working Groupdrafts and documents.Figure 2. SpaceVPX 3U Topologies Need an Onerous Number of Modules to Comply With the StandardSpaceVPXLite Control MethodNew Radially Distributed User Defined SignalsIn SpaceVPXLite, the 3U System Controllerconnects the utility signals directly to the payloadmodules instead of through SpaceUMs. Offloadingthese signals from the SpaceUM reduces it to justswitching power, so the SpaceVPXLite standarddesignates it as the Power Switch Module(PowerSX). It also enables the PowerSX module tonow switch supply power to at least eight payloadmodules: a vast improvement from two provided bythe 3U SpaceUM. Figure 3 shows the SpaceVPXLiteSystem Controller slot profile. To fit eight sets ofutility signals on a 3U System Controller, theSpaceVPXLite standard slims down the number ofsignals required.Signals retained include theSYSRESET*, REF CLK and AUX CLK sincethese signals are common to both the SpaceVPX andOpenVPX standards. System integrators can takeadvantage of this commonality by using OpenVPXpayload modules with SpaceVPXLite SystemControllers to improve single fault tolerance, or toprototype space hardened SpaceVPXLite payloadmodules.SpaceVPXLite adds user defined signalsRAD1 USR, RAD2 USR, RAD3 USR andRAD4 USR. The “RAD” part of the signal namestands for “radial” because these signals radiallydistribute, point to point, from the System Controllermodule to the payload modules. The standardassigns them as “user defined” because it does notallocate pins on the payload slot profiles for thesesignals to land on. Building in a few user definedsignals into the standard allows some flexibility toaccommodate unforeseen capability and invitecreativity in future implementations.REF CLK1 and REF CLK2 Re-AssignedSpaceVPXLite sacrifices the distribution ofREF CLK1 and REF CLK2 signals because thesepins now have a new purpose. Since SpaceVPXLiteplaces utility signals on the System Controller insteadof a SpaceUM, payload modules must nowaccommodate a redundant set of these signals from aredundant System Controller. REF CLK1 andREF CLK2 designated SpaceVPX payload module8A1-2

pins became the redundant AUX CLK andREF CLK for SpaceVPXLite.Likewise, theOpenVPX pin MaskableRESET* became theredundant SYSRESET*. In the current SpaceVPXstandard, 3U System Controllers do not includeREF CLK1 and REF CLK2 , so these pins are leftunused on 3U payload modules anyway.SpaceVPXLite now gives them a purpose asredundant AUX CLK and REF CLK .Figure 3. SpaceVPXLite System Controller Slot Profiles Provide All Utility Signals Needed to ConnectEight Modules into a System Plus Four User Defined Signals to Accommodate Unique FunctionsAssigning User Defined Signals in ProfilesConsistent with the OpenVPX philosophy,module profiles define a set of standardimplementations to address how to assign radiallydistributed user defined pins RADn USRxx, wherethe “n” designates signal 1, 2, 3 or 4 and “xx”designates the module it goes to. If the applicationrequires additional clocks where the payload moduledesignates four user defined pins as clocks, thenSpaceVPXLite allows the System Controller toconnect the SpaceVPX defined REF CLK1 andREF CLK2 to these pins.Consequently,SpaceVPXLite now adds SpaceVPX clockfunctionality formally restricted to only 6U modules.User Defined Signals to Implement IPMIAs another example, users may choose toimplement a radial distribution of the IntelligentPlatform Management Interface (IPMI) [5], withsignals IPMB SCL and IPMB SDA on two of thefour RADn USR pins. In this case, the SM(1:0) pinsconnect to IPMBA SCL and IPMBA SDA from theprimary System Controller, and the SM(3:2) pinsconnect to IPMBB SCL and IPMBB SDA from thesecondary System Controller.A system soconfigured effectively becomes a radial version ofOpenVPX using VITA 46.11 System Management.Direct Access Protocol on SpaceVPXLiteFigure 4 illustrates a SpaceVPXLite topologywhere the System Controller interfaces with thePowerSX over system management as described inthe SpaceVPX base standard as the Direct AccessProtocol. The SpaceVPXLite standard offers theopportunity to define a primary and secondary set ofSM(3:0) going to the PowerSX module because themodule and slot profiles are just now being worked8A1-3

out in the VITA 78.1 Working Group. For payloadmodules, however, SpaceVPX Direct AccessProtocol cannot connect with a SpaceVPXLiteSystem Controller because it defines only one set ofSM(3:0) pins, and it needs two sets for a dualredundant connection. Changing SpaceVPX payloadmodule pinouts after the standard achieves ANSIapproval disrupts product development, so the VITA78.1 Working Group decided to avoid new pinassignments as much as possible. If the final VITA78.1 standard allows a primary and redundant set ofSM(3:0) on the PowerSX, then SpaceVPXLiteSystem Controllers still command all the on/offpower switches to the payload modules just likeSpaceVPX using the Direct Access Protocol. Onlythe location of where the switching occurs differs,namely at the PowerSX instead of on the payloadmodule. If the PowerSX keeps only one set ofSM(3:0), then System Control still may use systemmanagement, but with the ubiquitous IPMB-A andIPMB-B rather than the Direct Access Protocol.Figure 4. SpaceVPXLite Topology for Six 3U Payload Modules Requires Two Less Modules than anEquivalent Topology in SpaceVPX; Also Adds User Defined Signals Tailored to Meet Unique NeedsSpaceVPXLite Utility Control DifferencesUtility control in SpaceVPXLite differs fromSpaceVPX in subtle ways. In SpaceVPX, the SystemController communicates over the systemmanagement bus using Direct Access Protocol toeach payload module through the SpaceUM. TheSpaceUM acts like a switch between the two SystemController’s SMB. Over this bus, the SystemController may command the modules to power on oroff as well as receive status among other capabilities.However, SpaceVPXLite does not include amandatory system management interface to payloadmodules. Instead, it offers options defined throughprofiles on the radially distributed user definedsignals. Providing flexibility in utility control for 3Uenables module suppliers to allocate less board areaand logic resources to system management overhead.As shown in Figure 4 and previously mentioned,modules may still implement system managementover I2C on the radially distributed user defined pins.The SpaceVPXLite approach allows SystemControllers to connect with ubiquitous openstandards such as SPI, UART as well as I2C topayload modules regardless of which pins theseservices map to on the payload module. Incomparison, SpaceVPX constricts utility control to aspecific protocol and pins for consistency and assuredinteroperability between compliant modules.8A1-4

Utility Signal Cross-StrappingCross-strapping of utility signals became anecessary element of SpaceVPXLite on account ofmoving them off the SpaceUM to make room formore power supply pins and support up to eightpayload modules. Each payload module must receivetwo sets of SYSRESET*, AUX CLK andREF CLK , but no OpenVPX or SpaceVPXdesignated pins exist to accommodate the redundantset. As a result, the SpaceVPXLite standard needs torepurpose existing pins. The easiest choice for aredundantSYSRESET*isMaskableReset*.SpaceVPXLite may use this signal unmodified fromOpenVPX because the OpenVPX standard includes apermission to allow using it as another SYSRESET*:“Permission 3.4.3-1: A Plug-In Module or RTMdeployed in an OpenVPX backplane may include asecond reset input from the backplane as acomplement to the SYSRESET* input.” OpenVPXprovides no such accommodations for secondaryAUX CLK and REF CLK , but SpaceVPX comesclose. It assigns REF CLK1 and REF CLK2 onpayload module user defined OpenVPX P1 pins.SpaceVPX allows user defined tailoring of both ofthese clocks. To use them effectively as secondaryAUX CLK and REF CLK , respectively, theSpaceVPXLite standard will need to include a rule sostating to convey to module suppliers the need tobuild-in switch-over capability. Figures 5 and 6show the “primary and secondary” connectionsbetween System Controller modules and payloadmodules.Figure 5. SpaceVPXLite Primary Utility Signal Connections from the System Controller Connect toPayload Modules on Pins Common with ANSI/VITA 65 OpenVPX8A1-5

Figure 6. SpaceVPXLite Secondary Utility Signal Connections to Payload Modules Rely on RedefiningSpaceVPX REF CLK1 and REF CLK2 as Secondary AUX CLK and REF CLK SpaceVPXLite Utility Signal SwitchoverThe SpaceVPXLite standard does not put intoplace a mechanism to determine which utility clocksand reset to listen to. If implementations place theredundant System Controller as always cold spared,then it does not matter. The payload module simplydoes an OR-ing of the primary and secondary inputs.If the implementation allows both switched on, thenthe payload modules must rely on the SystemControllers to correctly arbitrate control. If an erroroccurs where both System Controllers take control,due to an error caused by space single event effectsfor example, then the payload modules must rely onupstream processes to identify the rogue SystemController and shut it down. In SpaceVPX, thesecondary System Controller’s signals cannotinterfere with the primary System Controller’ssignals because the SpaceUM physically switches itout. But if the primary System Controller fails, thenthe upstream controller of the SYS CON SEL[5:0]signals must discover the failure and switch to theactive System Controller. Until the switchoverhappens, SpaceVPX payload modules have nocontrol and potentially no clock either.SpaceVPXLite on the other hand offers payloadmodules the opportunity to detect when the primarycontroller fails to automatically switch over to theredundant controller.Redundant Power Supply SwitchingBoth SpaceVPXLite and SpaceVPX performredundant power supply switching in one or morededicated modules. For SpaceVPX, the SpaceUMswitches between primary and redundant powersupplies under external control as commandedthrough discrete input signals. SpaceVPXLite doesthe same except it now uses a module called thePowerSX because it only does power switchingwhere the SpaceUM switches utility signals as well.8A1-6

PowerSX required. In this case, SM(1:0) from oneSystem Controller maps to SM(1:0) on the Payloadmodule and SM(1:0) of the other System Controllerroutes to SM(3:2) of the Payload Module. Thisresembles OpenVPX which assigns IPMB-A toSM(3:2) and IPMB-B to SM(1:0). Systems soconfigured use the PowerSX as a means to switchbetween primary and secondary input power sourcesonly.Both of these standards include the capability toswitch power to individual 3U slots.SpaceVPX Power Supply SwitchingIn SpaceVPX, the System Controller may switcha payload module on/off over the systemmanagement bus using the Direct Access Protocolover IPMB-A on SM(1:0) with SM STAT andSM RESET on SM(3:2). The SM(3:0) routes fromeach System Controller to the SpaceUM where itswitches to the selected System Controller beforegetting routed out to the payload modules.IPMI to PowerSX from System Controller P0A SpaceVPXLite System Controller provides upto eight utility plane interfaces to eight modules on itsP2 connector, but it also has one more utilityinterface on its P0 connector. In OpenVPX, theSM(3:0) pins on Chassis Manager slots connect withIPMB-A and IPMB-B. SpaceVPXLite leaves thesepins available for a similar function, but as a point topoint system management interface rather than amulti-drop one. These signals connect the PowerSXto the System Controller as shown in Figure 7. Inthis case, IPMBA on SM(3:2) goes to one PowerSXand IPMBB on SM(1:0) goes to the other PowerSX.Hence, the SpaceVPXLite System Controllerconnects with eight payload modules in addition totwo PowerSX modules.SpaceVPXLite Power Supply SwitchingSpaceVPXLite permits several methods ofpayload module power switching depending on thecapabilities provided by the System Controller andPowerSX.IPMI Direct to Payload ModulesIf the System Controllers support designatingtwo of the RADn USR signals on the P2 connectoras SM(1:0), then they can command payload powerswitching by direct connection to the payload moduleusing this IPMB. No power switching at theSYS CON1*/P*2Select ControllerSYS CON2*/P*Power22222System Management BusPower Feed B(P0:SM(3:0) plus SYSRESET*)Power Feed APower Supply BPayloadPayloadPayloadPayloadControllerPower SwitchPower SwitchControllerPayloadPayloadPayloadPayloadPower Supply ARedundant clocks and resetFigure 7. Eight Payload Modules Deploy in SpaceVPXLite with only Two PowerSX Modules and TwoSystem Controller Modules; System Management Bus Used for PowerSX Controls8A1-7

A known issue with I2C emerged in multi-droparchitectures where the interface tends to lock-up onoccasion under certain conditins. Even under the bestof conditions for space, single event effects couldcreate a lock-up condition. Though this may occurrarely, for space systems this would be a disastersince there is no one around to hit the reset button.SpaceVPX addresses this problem by replacingSM(2) with the SM RESET signal enabling theChassis Manager on the System Controller to resetjust the IPMC function on the payload modulewithout resetting the whole module withSYSRESET*. However, in the case of the PowerSX,the IPMC is the only digital logic function on theboard, so SYSRESET* effectively becomes theSM RESET. The PowerSX design would need toinsure that a SYSRESET* does not activate thepower switches and shut-off power to the SystemController. For the second SYSRESET*, the SystemController uses the MaskableReset* pin on the P1connector.SpaceVPX Direct Access Protocol to PowerSXIf the System Controller defines a SpaceVPXsystem management interface on its RADn USRsignals as shown in Figure 4, and the PowerSX hadan IPMC on-board, then slot power can be controlledas specified in the SpaceVPX base standard using theDirect Access Protocol. In the SpaceVPX topology,the SpaceUM switches the system management busto the payload module between redundant SystemControllers. For the SpaceVPXLite topology ofFigure 4, the system management bus goes no furtherthan the PowerSX where it controls power to allslots.Single PowerSX TopologiesIf the PowerSX has built-in fault tolerantswitches, then SpaceVPXLite offers an even morecompact system topology with just one PowerSXmodule as shown in Figure 8. Compared with the 3USpaceVPX topology in Figure 2, the SpaceVPXLitetopology has three fewer modules, but the samenumber of payload modules. This translates to lesspower and a 25% decrease in size and weight todeliver the same number of payload modules.Figure 8. SpaceVPXLite Gets Down to Just OnePowerSX to Support Eight Payload ModulesOpenVPX InteroperabilityBoth SpaceVPX and SpaceVPXLite interoperatewith OpenVPX modules with some limitations.OpenVPXmodulesknownothingaboutREF CLK1 ,REF CLK2 ,SYS CONP*,SM RESET, SM STAT or the Direct AccessProtocol defined in VITA 78 so these features cannotbe used with OpenVPX modules. However, bility. REF CLK1 and REF CLK2 simply provide a timing resource not essential tocomply with the SpaceVPX standard. For 3Umodules, SpaceVPX does not provide these signalson the System Controller slot profiles in order toconserve pins. SpaceVPX assigns SYS CONP* tothe OpenVPX general purpose I/O pin GDiscrete1pin. Many OpenVPX modules allow this pin to beconfigured as a general purpose input. As such, ifsoftware reads the state of this bit, then validates thestatus of SYS CON*, it effectively meets the intentof the SpaceVPX standard. SM RESET, SM STATand the Direct Access Protocol are defined for thesystem management interface on the SM(3:0) pins.OpenVPX only defines the physical routing of thesesignals and not their use. Although, OpenVPXbackplane profiles suggest using them as IPMB-Aand IPMB-B, a system can ignore these pins and stillcomply with OpenVPX. However, SpaceVPX doesrequire the SpaceUM comply with SM RESET,SM STAT and the direct access protocol, so anOpenVPX module cannot be used to interface with aSpaceUM as a System Controller.8A1-8

SpaceVPXLite Interoperability with OpenVPXSpaceVPXLite Slot ProfilesThe VITA 78.1 SpaceVPXLite standard is inWorking Group draft form as of the writing of thispaper, but the Working Group intends to preserveinteroperability with OpenVPX modules to thegreatest extent practical. A SpaceVPXLite SystemController may communicate directly with OpenVPXpayload modules over a radial distribution of thesystem management bus from an on-board ChassisManager as described above. Table 1 shows theOpenVPX compatible SpaceVPXLite SystemController module profile. When applied to all eight2-wafers sets of the utility management plane definedon the System Controller P2 connector, we achieveOpenVPX compatibility with the exception of dualredundancy support.Currently, no OpenVPXpayload slot profile exists that provides pins forredundant AUX CLK and REF CLK .Asmention earlier, SpaceVPX uses four OpenVPX userdefined pins on the P1 connector to defineREF CLK1 and REF CLK2 . SpaceVPXLite usesthese to land the redundant AUX CLK andREF CLK . Consequently, SpaceVPXLite supportsfull single string compatibility with OpenVPX. Toachieve fully radial and redundant utility signals forOpenVPX as well, the user defined signals on P1,row g, wafers 7, 9, 11 and 13 must accept redundantAUX CLK and REF CLK .A SpaceVPXLite System Controller includes allthe interfaces necessary to directly control resets andclocks as well as provide control communicationsover the Control Plane. On the second connector(labeled P1) from the top of Figure 3, eight DataPlane ports map to eight Thin Pipes (TPs). A TPconsists of four differential signals on two wafers.SpaceVPX and SpaceVPXLite module profilesassign SpaceWire to these TPs. OpenVPX profilestypically use 1000BASE-T Ethernet on TPs. Thebottom connector on the SpaceVPXLite SystemController Slot Profile shows another eight TPs forUtility Management. The table on the upper right ofFigure 3 breaks out the TP into specific signal types.The first three: SYSRESET*, AUX CLK andREF CLK are required utility signals forOpenVPX, SpaceVPX and now SpaceVPXLite. Thenext four signals, RADn USR are user defined andspecified further by Module Profiles.Table 1. SpaceVPXLite System ControllersInteroperate with OpenVPX Payload ModulesSpaceVPXLiteDesignationSYSRESET*AUX CLK REF CLK RAD1 USRRAD2 USRRAD3 USRRAD4 USROpenVPX CompatibleSystem Controller ProfileSYSRESET*AUX CLK REF CLK SM(0)SM(1)User DefinedUser DefinedSystem Controller ProfilesSpaceVPX and SpaceVPXLite adopt the slotand module profile definition scheme of OpenVPX.The Slot Profile identifies the type of signals used foreach pin on the backplane connector. Each ModuleProfile identifies the specific signal for that type.SpaceVPXLite Module ProfilesThe two tables in Figure 4 and Table 1 showthree possible Module Profiles for the SpaceVPXLiteSystem Controller.The SpaceVPX andSpaceVPXLite standards define these profiles inmore detail, but these three tables show examples ofhow they define different sets of pins among the eightTPs on P1. Module Profiles identify all the interfacesselectable in the standard that fit into these TPs. Twopossibilities include SpaceWire or 1000BASE-TEthernet. The System Controller Module Profileshown in Figure 4 shows a different definition for theutility TPs depending on whether the SystemController interfaces with a payload module or aPowerSX.In this case, SpaceVPX systemmanagement over SM(3:0) provides the interface tothe PowerSX. Yet, the PowerSX is a much simplerdevice than the SpaceUM, so a simpler interface maysuffice. A System Controller supplier will likely usea field programmable gate array (FPGA) device forthe utility TPs to enable support for a broad range ofinterface types on the RADn USR pins.Backplane TopologiesThe SpaceVPX Systems Specification standardincludes several backplane profiles showing usage ofthe slot profiles in a topology. These profiles show a8A1-9

connection diagram of how all the signaling planesand power get routed into a topology. Thesesignaling planes include the Control Plane, DataPlane, Expansion Plane, Management Plane andUtility Plane. In comparison, Figures 2, 4, 7 and 8showed only utility plane connections wherebackplane profile BKP3-DIS12-15.2.9-n, shown inFigure 9, also shows the other signal planes. Thisprofile shows a typical 3U SpaceVPX topology witha central switch connecting the Control Plane and amesh connected Data Plane. For six payload slotsand two controller slots, we need four SpaceUMs,two per slot. Backplane profiles do not need tosupport all planes. In this example, no ExpansionPlane exists due to the limited number of pinsavailable on a 3U module.the right of the chassis then to the PowerSX beforegetting distributed to the digital slots. In comparisonwith Figure 9, the SpaceVPXLite topology achievesthe same number of payload modules, but with a totalcompliment of three fewer modules overall toimplement the topology.Payload SlotsSwitch & Control PowerSwitchPayload PlaneContrlPlaneContrlPlaneVPX9PowerSupply AVPX10PowerSupply BVPX11SwitchControlFigure 10. SpaceVPXLite Equivalent Profile toBKP3-DIS12-15.2.9-n Needs Only One PowerSXBackplane Routing AlternativesFigure 9. Typical SpaceVPX 3U BackplaneProfile BKP3-DIS12-15.2.9-n Needs 4 SpaceUMsSpaceVPXLite Backplane ProfilesFigure 10 shows a SpaceVPXLite equivalenttopology to the one shown in Figure 9. In theSpaceVPXLite topology, the System Controllermodules reside in slots 4 and 5 with the PowerSX inslot 9. The Utility Plane signals connect in the sameway as the topology shown in Figure 8, but with theslots in a different order. A card slot arrangementsuch as shown in Figure 10 has advantages in cablerouting and EMI control by bringing power in fromTypical VPX and OpenVPX implementationsuse backplanes for connectivity, but recentdevelopments may soon render backplanes obsolete.VPX emerged to provide a backplane connector andstandard pinout to handle high speed serialinterconnects up to 6.25 GBaud. Some companiesreport satisfactory results up to 10 GBaud with thesame connectors [6]. However, with technologymoving rates to 28 GBaud and beyond, “an importantalternative technology for the future of high speedserial link backplanes is using cables” as cited by Dr.Eric Bogatin at DesignCon 2014[7].Cabling from Rear Transition ModulesTo stay alive and gain widespread adoption, astandard must accommodate advances in technology.VPX, and by way of inheritance OpenVPX andSpaceVPX, provides a convenient means tointerconnect without relying on backplanes forconnectivity. ANSI/VITA 46.10 “Rear TransitionModule for VPX” defines a module andinterconnections to attach directly to the backplane8A1-10

edge connector [8]. This module converts signals,intended for backplane transmission, to insteaddrive/receive over coax cables or fiber-optics.Figure 11 shows how an RTM connects to a 6USpaceVPX module. In addition to providing thenecessary interface electronics, the RTM offers theconnectors and I/O assignment to align with otherstandards such as the SpaceAGE Bus [9]. SpaceAGEuses frames instead of backplanes. A SpaceVPXLite3U module with backplane and RTM all fit within themechanical envelope of the SpaceAGE frame.network switch. Having these signals enter throughthe backplane side of the module typically simplifiescable routing in the host platform.Platform Host Hook-UpWe have covered how SpaceVPXLite systemcomponents hook-up together, but eventually it needsto hook-up to a host of some type. SpaceVPXLitehas the same interfaces as SpaceVPX for the hook-upto a platform controller.Utility Signal Hook-Up to HostFigure 11. RTM Breaks-out SpaceVPXLite 3UModule I/O to Cable ConnectorsCoax and Fiber-Optic Direct Attach CablingTwo other alternatives to routing high speedserdes on the backplane include coax cabling withANSI/VITA 67.x and fiber-optic cabling withANSI/VITA 66.x [10, 11]. These two standardsdescribe ways to include blindmate coax connectors,fiber-optic connectors or a combination of both into aVPX module. A 3U OpenVPX system using bothstandards has been proposed by Peddicord [12].Recent activity by the OpenVPX Working Groupalso includes adding more of these types of profiles.Coax brings RF signals into the module using 67.xand serdes over fiberoptics per 66.x attaches it tohigh-speed communications by way of an externalFigure 12, shows pins on connector P0 assignedto REF CLK , AUX CLK , and SYSRESET* thatalso match with the VPX standard pin assignments.These pins connect to the platform to establish amaster source for these signals. The platform alsoeither drives the SYSCON* signal, along with paritysignal SYSCONP*, to select the active SystemController or straps them with jumpers. A separateset of signals, called SYS CON SEL(2:0), go to thePowerSX to switch power on to the selected SystemController. If the platform needs to make crossstrapped connections, then a second set ofREF CLK , AUX CLK , and SYSRESET* connectup to the REF CLK1 , REF CLK2 andMaskableReset*, respectively, in the same manner asutility signals connect from System Controllermodules to payload modules.Finally, thePOWER SEL(2:0) signals go to the PowerSX toselect which of the redundant power supply inputs touse to power all the modules. Separate from thesepower supply inputs, a persistent, low current sourceprovides power to the PowerSX for the switches andsystem management control circuits.8A1-11

Figure 12. System Controllers Have Their Own Utility Signal Pin Endpoints for Connecting to a MasterSource of Clocks and Resets; Or, for Cascading from Other System Controller ModulesControl and Data Plane Hook-up to HostThrough these required interfaces, the platformhost selects which input power supply to use andwhich Sy

Standard (NGSIS) [2]. The VITA 78 standard has similar structure as the ANSI/VITA 65-2010 [R2012] OpenVPXTM System Specification [3]. OpenVPX rapidly gained broad adoption for avionics systems after its introduction in 2010. It is based on the VPX standard (Versatile Performance Switching) which is defined by ANSI/VITA 46.0-2007 [4]. The VITA 65