Embed Size (px)
Citation preview
Reconfigurable Computing Concepts for Space Missions:Universal Modular Spares
M. Clinton PatrickNASA/MSFC/EV43
Marshall Space Flight Center, AL 35812256-544-3836
Abstract_omputing hardware for control, data collection,and other purposes will prove many times over crucialresources in NASA's upcoming space missions. Ability toprovide these resources within mission payloadrequirements, with the hardiness to operate for extendedperiods under potentially harsh conditions in off-Worldenvironments, is daunting enough without considering thepossibility of doing so with conventional electronics. Thispaper examines some ideas and options, and proposes someinitial approaches, for logical design of reconfigurablecomputing resources offering true modularity, universalcompatibility, and unprecedented flexibility to service allforms and needs of mission infrastructure.12
TABLE OF CONTENTS
1. INTRODUCTION ...................................................... 1
2. CORE CONCEPTS IN RC ........................................ 1
3. APPROACHES ......................................................... 44. PRACTICAL MATTERS ........................................... 75. CONCLUSIONS ....................................................... 7REFERENCES ............................................................. 8
BIOGRAPHY ............................................................... 8
1. INTRODUCTION
Reconfigurable Computing (RC) research oversight atMarshall Space Flight Center has since 2006 fallen underthe Radiation-Hardened Electronics for Space Exploration(RHESE) project. This is partly because of a need toprovide avionics systems that are more robust in harsheroff-World environments, and in part simply because theapproach to providing systems for Space should logically bean integrated one.
ReconfigurabilityDefined
To gain an understanding of reconfigurability in the currentcontext, it may be most useful to contrast it with what it isnot: it is not reprogrammability, although it can possesscharacteristics of reprogrammability. In a conventionalserial system, based on a central processing unit (CPU),changes are effected by modifying commands (or OP codes)for specific operations to be executed, along with their orderof execution, all in fixed hardware resources. That is, the1t U.S. Government work not protected bY U.S. copyright.
2 IEEEAC paper #1503, Version 2, Updated October 22, 2007
CPU has portions of its circuitry which are dedicated toexecuting particular algorithms in particular ways to ensurespecific outputs result when specific inputs are applied.Furthermore, in most cases only one copy of each algorithmexists in one particular location on a physical device, inperpetuity, and cannot be modified without redesigning andproducing a new device.
In contrast, reconfigurable computing places circuitry forspecific algorithms where needed, and as needed. In otherwords, multiple copies of each piece of circuitry may beplugged into data flow paths where needed, with nocircuitry wasted on unused algorithms. If a new algorithm isneeded that was not previously realized in hardware,available resources may be configured - or freed andreconfigured - to meet that need. And if a characteristicallyserial process proves more efficient, that may also beaccommodated.
2. CORE CONCEPTS IN RC
Reconfigurability in Context
Regardless of technical intricacies, it is good to keep an eyeturned toward potential benefits. To that end, an example isin order one very relevant to Space flight.
Most conventional Space-related systems utilize a host ofcustom avionics boxes for each of the tasks and stages of a
mission. Engine controllers operate during launch andascent, Emergency Detection System (EDS) hardwaremonitors potential abort conditions and responses, flightcomputers calculate interplanetary trajectory and make
adjustments, specialized electronic boxes oversee andcontrol various stages of rendezvous and docking (bothlong- and short-range portions), computers in landingvehicles handle descent and landing operations, surface
rovers perform all manner of closed-loop control, and so on.For most of these processes, a particular computingresource is used for a limited period and then shuts down; in
many instances, periods of operation do not even overlap.
Suppose, then, that individual computing resources could
oversee many of the independent processes or limitedsubsets of overlapping processes listed above. Duringlaunch, engine and abort operations are maintained; in
https://ntrs.nasa.gov/search.jsp?R=20080018959 2018-06-28T10:35:05+00:00Z
extraterrestrial travel, navigation functions are performed;from long-range, radar is wired in to guide the vehicle toclose proximity with an orbital facility; camera systems arethen configured in to monitor and execute dockingprocedures; then the same camera systems are used duringde-orbit and landing. At this. point, computer and camerasystems from the vehicle can be transferred· to· a surfaceroving vehicle, might be held as a spare for any system, orcould instead be used for life support ina habitat module.
Various other basic concepts have come to be recognized.These include what atleast for now will be called Levels,Granularity, and Complexities of Reconfigurability. Also,RC efforts at NASA have come to be separated into threeprimary areas of concentration: Interface Modularity,Processing Modularity, and Fault Mitigation. Each of theseconcepts will be touched on below; note,however, thatbecause of a very real degree of inseparability of the ideas,much overlap can be expected in their descriptions.
For more conceptual and historical perspective on RCtechnologies in general, see [1].
Levels ofReconfigurability
Levels of reconfigurability are, very briefly, a gauge of thephysical strata at which an RC system is reconfigurable.These are currently delineated from macro to micro-levelsof definition as: Box, Board, Chip, and Gate levels.
Granularity
The degree to which an RC system is reconfigurable mayalso be distinguished by a rough estimate of granularity, aterm more widely recognized both inside and outside thefield of RC. For example, systems composed primarily ofbanks of interconnected field-programmable gate array(FPGA) units (often called "FPGA fabric" or moregenerally "reconfigurable ·fabric") can be reconfigured atthe logic gate level, and thus are considered fine-grained. Incontrast, a system based on Field-Programmable NodeArrays (FPNA) or Field-Programmable Object Arrays(FPOA) does not have such low-level reconfigurability andthus ranges from medium-grained to. coarse-grained. Asystem based only on b()ard-level reconfiguration fallssquarely in the coarse-grained category[2].
Complexities ofReconfigurability
This account outlines four different complexities ofreconfigurability: Basic, Physical Spares, Automatic, andAutonomous Reconfigurability.
Basic Reconfigurability--This is the heart of RC research:leveraging a core ability to change algorithms and interfacesin a piece of hardware to address various changingdemands. This typically centers either on timesharing thesame hardware resource in a given system for many
2
different purposes, or on upgrading hardware functionalityas necessary.
Physical Spares Recorifigurability--Modular RC sparesprovide the capacity to use identical hardware in differentsystems. Crucial to this is the ability to leverage basicreconfigurability of a given computing resource for widelyvarying operations when interchanged among differenttarget systems. One very important appeal of this is theresulting potential for reducing total number (and payloadweight) of flight spares.
Automatic Reconfigurability--Automatic reconfigurabilityprovides the ability, either through direct commands or pre~
determined procedures, to modify the architecture andbehavior of given circuitry for carrying out significantlydifferent computing functions.
Autonomous Reconfigurability--This is the most complexand most desirable - ability for an RC system to possess. Itis the capacity to reconfigure without external direction oroversight, and drives more at self-adaptation than theprevious complexities. While this does not exclude theapplication of predetermined algorithms for effectingchange, it is intended primarily to designate evolutionarytechniques utilizing intelligent adaptation, such as geneticalgorithms and neural networks.
As can be seen, each of these concepts relies heavily uponsuccessful implementation of all prior concepts. None canexist without the underlying abilities. Progress indevelopment of technology will follow in step-wise fashion:first, with modules that can be manually reconfigured fordifferent tasks in a given. system; then versions that can bemanually reconfigured for Use in different systems; thenversions that will automatically reconfigure based uponprompts from· the system in •which they· are currentlyinstalled, with capability .built along the way to timesharethe computing resource among multiple tasks; then withfeatures added systematically to enable fault checking andmitigation, self-repair, and' advanced autonomousreconfiguration and adaptive behavior.
Interface Modularity
Interface Modularity, or External Modularity, is that portionof a reconfigurable system most critical to its functionalityas a universally modular piece of hardware. This featuremakes it possible to interchange computing resources fromdifferent vehicles or applications, each possibly withdifferent communication and interfacing schemes.
Because much of the current capability in RC is centeredupon use ofFPGAs and related programmable logic devices(PLDs), it is fortunate some devices are beginning toinclude embedded or downloadable (some from third-partyvendors) capabilities to match various standard protocols;take, for example, provisions for Ethernet and RocketIO in
the Virtex-5 product from Xilinx, along with modules forinterfacing through RS-422, RS-485, and othercommunication standards.
A new effort capitalizes on this concept: the UniversalReconfigurable Translator Module (URTM) is being built todemonstrate at least three different bus conventions in asingle package, with capability to reconfigure interfaces asvarious applications require.
Processing Modularity
This has in recent past been called either InternalModularity or Spares Modularity. The former term seemsambiguous, while the latter better fits a complete RC systemincluding interfacing modules.
Core ability to modifY functionality of a system, as depictedin Figure 1, stems from this aspect of RC. The chief featureof interest here is a capacity to fundamentally modifYunderlying logic circuits and interconnections. Regardlessof the specific means by which reconfiguration is achieved,this must be flexible to some extent specifically at the subboard, sub-chip or circuit level. It must also take placeprimarily as a substantial change in actual hardwareconfiguration. To clarifY this point: a conventional systembased upon a central-processor unit (CPU) is admittedly
exceptions - by modifYing software only. Also note that RCsystems may very well incorporate CPU-based technologiesin various forms, either in reconfigurable or nonreconfigurable, embedded, varieties.
Radiation Tolerance and Fault Mitigation
At some point, and to varying extents depending uponspecific applications, RC will be applied to harshenvironments such as Space, with related requirements forenvironmental tolerance and tasks of error detection andresolution.
Inherent Fault Mitigation Benefits ofRC-First, because thetechnology is inherently more distributed than aconventional CPU-based computing device, RC devicesshould also be inherently less likely to exhibit negativebehavior or sustain catastrophic damage in the event ofradiation events. Since all of the computing activity in aCPU must pass through the central processing point's"bottleneck," radiation damage at that one point wouldpractically guarantee complete loss of device functionality.With the more distributed RC approach, this particularcentral vulnerability does not exist.
Another benefit of RC technology seems almostserendipitous. Highly parallelized hardware to date usually
GroundCommunications
OnboardCommunication
Figure 1 - RC Modules: Building Blocks for RC Processor ModularityDifferent colors/shades illustrate modularfunction interchangeability, with return arrow paths indicating potentialfor
modified algorithms orfunctionality being storedforfuture use
adaptable to accomplishment of different tasks, but itsreconfiguration is accomplished - with few if any
3
comes with lower system clock speeds, realizing totalthroughput advantages through execution of massive
n~mbers of operations simultaneously. Because circuitswith lower clock speeds tend to naturally have moreradiation tolerance, fewer EM! issues, and better robustnessin general, this can be considered an altogether agreeablebonus.
RC Techniques for Fault Mitigation~ The idea ofHardware Swapping, or simply utilizing modularcomputational resources to provide hardware· spares formultiple systems, further allows capability for providingcomputing resources for missions in harsh environments orfor exceptionally long terms, swapping subsystems or entiresystems as needed. This is a low-hanging fruit, and as suchwill be demonstrated in the near future, likely much soonerthan may be expected of other fault mitigation concepts.
In the event of permanent damage to particldar points,circuit resources can be replaced, with reconfigurationaround the damage. This brings up concepts of an "RC ashard disk" approach and "circuit paging.." The f9rmermarksoff bad portionsqf a circuit, once identified, sutting themfrom reserve resources much as is done with bad memoryblocks in a hard disk controller. The latter invotyes~eepingone tested copy of circuitry on standby, in order to allowperiodically swapping out and running diagnostic~on theoperational copy.
Fault Mitigation Benefits Unique to RC-A few newcapabilities exist .solely •because of the advent ofreconfigurability. .One exciting possibility is presented hereas perhaps the most novel concept in this paper: fused subcircuits.
In conventional electronic systems, catastrophic events .suchas power-to-ground shorts generally trigger a domino effectprogressing through failures at. the device, board, and boxlevels, typically ending when a power breaker is thrown.Unfortunately, this also leaves the system with nofunctionality.
Proposed here is the concept of fusing or otherwiseprotecting subsets of a device to enable isolation of failedportions. Failure of subsections of the device might resultin a system reset, but upon recovery the system should becapable of replacing lost functionality in reserve locationsand continuing as before.
Any number of sources for single-point failures will exist indevices in future RC applications. While mitigationtechniques will address many of these, it will be interestingto see what other new ideas· are developed to' advance thecircuit level of the art.
Finally, it is possible that current practices of multi-stringredundancy and voting may one day become obsoletebecause of RC. If it is possible to flag significant decisionsby single-string processes, recreate the conditions and therelevant circuitry and double- or triple-check the results
4
before action must be taken, substantial circuit complexityand system development effort may be eliminated withoutadversely impacting safety and reliability.
3. ApPROACHES
Crewed Flight
Requirements and considerations for various approachesdepend upon particular applications. One primarydistinction is of crewed verses uncrewed missions. Anargument here is that for crewed systems reconfigurationswill be attended, and can thus involve modular, universalelectronic units replaced by hand. In the case of uncrewedmissions, human interaction will be limited to remotereconfiguration only of installed hardware; although it canbe argued that robotic .units could. perform physicalreplacements, that argument will be neglected for now.
The idea of Hardware Swapping, or direct utilization ofReconfigurable Spares, applies most readily to crewedexploration. This is obvious when.one cqnsiders availabilityof a human to pull spare hardware out of inventory or swapcompatible hardware from an inactive or less criticalsystem.
Consider the number and variety ofvehicles and subsystemsrequired to accomplish launch, staging, interplanetaryoperations, automated rendezvous and docking (AR&D),landing, and operation of remote outposts. It follows that aready supply of modular spare parts could exist, assuming aphilosophy of Spares Modularity is established now andfollowed throughout planning and development.
Finally, it is worth noting differences among spares pulledfrom active use in other equipment, spares held in unpowered status in other equipment, and spares pulled fromstorage. In long-term mission applications, it is important toconsider circuit lifetimes based on these differences; basicin-service time, time spent installed un-powered or inpowered standby status, standard shelf life in exposure toambient radiation and other impacts, and un-poweredstorage in shielded vaults. With the capability to physicallyreplace hardware, assemblies, the latter option is made muchmore readily available.
Uncrewed Operations
Without human presence, ability to make changes tosystems must obviously be much more highly automated.As noted, provision of robotic systems to carry outequipment repair and replacement in lieu of humaninterventi<i>ll is a possibility; however, this carries its own setof tradeoffs which will not be argued here.
Humans can still intervene remotely, by uploading changesor commanding implementation of preset reconfiguration
options. This approach works up to a point, depending uponthe distance of separation of humans from the system andthe skill of designers in predicting contingencies; it becomesan unpalatable option as communication delays becomeincreasingly significant.
. One avenue under consideration would apply adaptive orevolutionary techniques. This includes but is not limited toneural networks and genetic algorithms. It is recognizedthese are controversial technologies, especially inapplication to space-qualified systems, but their potentialshould not be overlooked. Furthermore, these approachesare much more likely to be accepted first for use inuncrewed systems than for human-rated ones.
Figure 2 - Building an RC FabricWith multiple reconfigurable modules, multipleinterconnection paths, and redundant busses
With the inability or reduced ability to enjoy the option ofhardware swapping reconfigurable spares, the various faultmitigation options mentioned above become much moreappealing. Lacking any ability to physically swap hardware,circuit lifetime issues become much more pressing for longterm missions. It thus becomes crucial to consider varioustechniques for error detection, failure detection, andmitigation: in essence, an arsenal of self-monitoring andself-healing tools.
Concepts in Modularity, and RC Implementation
Modularity necessary to realize much of the technologicaladvancement discussed herein can be implemented in awidely varying number of ways. This section touches onbasic philosophies adopted so far in approaching theproblem.
5
Collection of RC modules into useable RC fabric (forexample, Figure 2) will always require craftiness on the partof designers. The usual tradeoffs must be made, betweencapacity and power consumption for example. In addition,interconnection of the modules may be accomplished in somany different ways as to be prohibitive. Here, a majortradeoff must be made in local interconnection pathsamongst individual modules vs. connections necessary for asystem-wide bus. Note that what is represented as businterconnections here may not necessarily be interpreted asclassic bus wires; rather, it is possible for interconnectionsbetween modules and clusters to also be reconfigurableresources.
Given the assumption RC modules are in fact modular units,it follows that repair of failed hardware may beaccomplished by replacement of subsets of systems ratherthan full replacement (Figure 3). What remains to bedetermined are such issues as whether to realize the entireset of system computing resources in RC hardware, or toonly use RC as backup hardware for conventional systems.Note that in either case, interfacing of primary or backupsystems alike must handle changes in access to dataacquisition and sensor systems: in other words, peripherals.
Figure 3 - Physical System Repair Concept
As a very closely related SUbJect, developments mFPNAIFPOA technologies are followed with great interest.These should offer tradeoff's in granularity verses ease ofimplementation in the near term, where fine-grainedsolutions will likely call for many more years ofdevelopment prior to marketable products.
In currently emerging products, nodes are clustered in setshaving a desired representation of various computingstrengths (See Figure 4). In some cases, the distribution ofcapabilities is customizable prior to production of targetdevices. Most nodes are capable of addressing any numberof specific applications or algorithms; for example, one type
RC Node Cluster
Figure 4 - FPNA/FPOA Semi-Custom RC FabricsColors/shades here represent predetermined distribution
ofapplication-specific or specialized nodes
of node may easily work ground communication, on-boardcommunication, and general system interfacing tasks. Thespecific application might take only a portion ofone node inone cluster, or could be distributed across multiple nodesand clusters. The development environment forprogramming and controlling such a device, or networks ofthem, is one major aspect of delivering FPNA technology.
System-Level Approaches
Not surprisingly, a variety of plans may be pursued inrealizing a functional system definition for RC technology'sapplication. The following figures illustrate conceptually afew of these. The underlying assumption is that RC mightbe adopted at least initially only on a very limited basis,while in the long term its continued use would drive towarda much more thoroughly integrated strategy.
Because conventional systems usually consist of custom anddedicated electronic boxes connected directly to sensors andother interfaced resources, as Figure 5 shows, applying anRC system as a modular spare in such an environmentmight not be as straightforward as hoped. In the event offailure in a primary module, access to these resources wouldmost likely be compromised.
6
Figure 5 - RC Cluster in Conventional SystemWith Conventional Peripheral Interfacing
For this reason, it might be necessary to invest inpreplanned modifications to system integration strategies.One such change could involve bussing sensors and otherresources along with regular data bus signals, in order toenable access to their resources by any subsystems requiringthem upon reconfiguration (Figure 6).
Figure 6 - RC in Modified Conventional SystemBussed peripheral interfacing enables access ofbackupsystem and ensures full recovery upon primary system
failure(s)
Ultimately, an RC system could be implemented as auniversal resource, as depicted in Figure 7. Here, the term"universal" might be considered multifaceted; that is, theRC system is able to replicate any onboard subsystem, but itmay also be used effectively in practically any number of
Figure 7 - RC as a Complete System ResourceAdditional cluster represents expandable modular
reserve circuit capacity
vehicle and other infrastructure systems. The primarydrawback is that this universality must be designed in aheadof time for such broad physical and functional compatibilityto be possible.
Application Demonstrations
A number of applications have been targeted fordemonstration in systems under consideration forimpending research. These applications have been chosenfor relevance to a wide variety of efforts, in order toshowcase flexibility of developing RC systems and to aid inresearchers' grasp of concepts.
At this time some of the applications are general while someare more specific. Replication of microcontroller,microprocessor, and digital signal processor capabilities areexamples of the former. The latter includes demonstrationsof closed-loop control as with a motor, motor controller,and shaft position encoder; video or other image acquisitionand processing subsystems; and software-defined radio.
The URTM effort mentioned previously is directed atdemonstration of RC-based interface modularity
Further efforts will provide examples of data handling,science data analysis, general number crunching, trajectoryprojections, or other capabilities relevant to upcomingmissions. These will be directed at demonstration ofprocessing modularity.
7
4. PRACTICAL MATIERS
RC technology hasn't yet landed with full force in the realworld. Its potential is enormous, and will continue to growand evolve as the technology begins to mature. In the fardistant future, it is conceivable that RC systems willdisplace or even replace software-based operating systemsand software itself, as we know it.
In the meantime, there are some very real problems inimplementation. At the forefront of the field is thetechnology that essentially started the whole thing: FPGAs.While these have exceptional applicability and flexibility inlimited applications, when incorporated into fabrics theirconfiguration, programming and use becomescorrespondingly more complex. Reprogramming FPGAswhile they run is of immense interest to modemtechnologists; however, this process is still relatively slow,in that it cannot yet be accomplished between system clockcycles. Furthermore, densities of logic possible at this timeare still limited and power consumption is an exceptionallyproblematic issue. On a basis of performance vs. poweralone, FPGAs currently prove to be a poor choice forprotracted systems - especially in applications for Space.
On the other end of this spectrum, Application-SpecificIntegrated Circuits (ASICs) often have remarkable powerand space characteristics, but prove too expensive. And afurther key point is that they basically can't be reconfiguredat all.
Most devices available for research today have little or noaccommodation designed in for radiation-related issues.That means few are radiation tolerant, let alone radiationhardened.
For the time being, emerging technologies in fieldprogrammable node arrays (FPNA) or field-programmableobject arrays (FPOA) deserve attention. These promise animpressive tradeoff of FPGA flexibility with ASIC speedand low power consumption. That nodes or objects may beredundant promotes such ideas as self-checking, circuitreserves, and self-healing needed for fault-tolerantarchitectures and systems required to perform on longduration missions.
5. CONCLUSIONS
The relatively new field of RC promises entire sets of newtools for addressing needs of the Space community foravionics and other computing capabilities.
RC has a virtually unlimited potential for modularity. On avery basic level, modularity makes a lot of sense. Hardwaredevelopment, flight qualification, spare parts logistics, andmany other aspects of electronic provisioning become vastly
simplified if they only need be done once for multiplesystems.
Nevertheless, it must be admitted that implementation ofthis vision will not be simple. Many systems exist nowpartly because the many people building them havedifferent ideas about how such things should be done. Thistechnological inertia is typically hard to overcome; when anentirely new paradigm is considered, a whole additionallayer of resistance can be expected.
Still, the potential for higher efficiency is tantalizing:universal spares, and the accompanying savings in space,power, payload weight, design time investment, flightqualification effort, and other costs, are expected to drawenough interest in the near future to move the revolutionalong to its next exciting stage.
REFERENCES
[I] Robert L. Jones and Robert F. Hodson, A Roadmap forthe Development ofReconfigurable Computing for Space.Version 2.0, March 2007. Internal NASA document(currently unpublished); contact this paper's author foraccess.
[2] Clive "Max" Maxfield. The Design Warrior's Guide toFPGA. Burlington, MA: Newnes, 2004.
BIOGRAPHY
Clint Patrick is an ElectronicsEngineer at MSFC. He has beenwith NASA more than twenty-sixyears, working in electronic datasystems; circuit design, layout andproduction; FPGAs; systemintegration; system softwaredevelopment; spectroscopy; artificialneural networks; and reconfigurable
computing. He is currently NASA's RC task lead for theRHESE project.
8
