Glenn Rakow, SpaceWire Development Lead, Goddard Space Flight Center
- Created on Sunday, 01 February 2009
Glenn Rakow is the Development Lead for SpaceWire, a high-speed communications protocol for space-flight electronics originally developed in 1999 by the European Space Agency (ESA). Under Rakow’s leadership, the SpaceWire standard was developed into a network of nodes and routers interconnected through bi-directional, high-speed serial links, making the system more modular, flexible and reusable. In 2004 Rakow was named the recipient of Goddard’s James Kerley Award for his innovation and contributions to technology transfer.
NASA Tech Briefs: What is SpaceWire technology and how does it work?
Glenn Rakow: SpaceWire describes a spacecraft’s onboard data bus that was standardized by the European Space Agency under European Cooperation for Space Standardization. Basically, it’s a method for interconnecting spacecraft components similar to the way Ethernet hooks up computers in the office, except it’s optimized for the space environment. We care a lot about mass and power, so much so that we had to deviate from commercial standards to optimize it for those parameters. Not only power and weight, but we also want to optimize it for flexibility.
So again, it’s a European standard that we have been participating in the development of from the get-go, and it’s become kind of the de facto standard now, at least for high-speed data bus or networks for onboard spacecraft in the U.S., and it’s actually becoming the standard for ESA and the Russian Federal Space Agency, for which the acronym is ROSCOSMOS. They’re basically using it as well for most of their applications.
NTB: As you’ve noted SpaceWire was developed by the Europeans around 1999. How did you get involved with the technology?
Rakow: Actually I was involved with it back then as well. I was kind of independently looking at a previous IEEE standard, which was the precursor to SpaceWire called IEEE 1355. I had started looking at that back in 1998, but that standard had a lot of problems. It was basically not well defined and you couldn’t have given it to two independent people and developed a product that was compatible between those individuals. It had some inconsistencies and some vagueness that didn’t permit a solid design that could work with independent groups.
So basically I started working with that one and clarifying it while the Europeans were doing the same, and we had met and compared notes, and we basically had similar assumptions. I had a design based on my assumptions, and they had one, and there were some slight differences, so what I did was I adopted the differences in favor of ESA and we pretty much had SpaceWire from a very early stage. Before it was standardized we had a design that was up and running. We actually flew the first version of it on a mission called SWIFT, which is a gamma ray burst alert telescope. It catches gamma rays, which are very fleeting events, and quickly reports the detection of a gamma ray in less than a minute so that observers from around the world can quickly look up in the sky and see the gamma ray burst. So we flew the first version of it on SWIFT.
NTB: That was in 2004, correct?
Rakow: It was launched in 2004, but we actually developed it in 2000, 2001. The development cycles of these things are typically 3 or 4 years, so we had the development of it working well before 2004.
NTB: Is it currently being used on any other missions?
Rakow: That’s the only mission that’s currently on orbit from our side. We have boards and systems at the flight level for JWST – the James Webb Space Telescope. We’ve been developing the technology for that mission for years and we have prototypes and flight units working and integrated into the system. It’s to be launched in 2013. The technology is far enough advanced that we have flight units that have it in them.
NTB: What will it be used for on the James Webb Space Telescope?
Rakow: It’s basically used as the network that interconnects the instruments to the data processing unit and to the recorder. If you follow the data flow, SpaceWire is the bus that takes it from the instruments to the data processor and then back out to the recorder for storage.
It’s also being used on GOES-R, which is the NOAA/NASA geosynchronous weather satellite. GOES-R is kind of the flagship project for all future GOES satellite developments. It basically is being used to collect the weather data and pipe it to the ground. It’s also the data bus that the spacecraft will use to communicate with all of its components.
NTB: One of your major contributions to SpaceWire technology has been Goddard’s Link and Switch implementation of the SpaceWire protocol. Can you explain what the Link and Switch router does and how it works?
Rakow: SpaceWire basically describes the network, so it’s a point-to-point switch fabric, which means the network’s comprised of individual links which can be scaled to create a switch fabric through routers. So you can kind of think of it as, you’ve got a router and you can hook these things into the other routers, and eventually you get to an end node which is a link, and there’s no more routing done. It’s where the source of the data originates, or the destination of the data. That’s what’s called a “link.” A router is the switch; we use switch and router interchangeably, but basically the router and switch are one and the same. So by taking the links and the end nodes and hooking them up to switches, that’s how you form your switch fabric or your network. Basically, we have routers, or switches, and we have end nodes, and we have both designs which are required in a system.
NTB: How has the SpaceWire standard evolved and changed over the last nine years?
Rakow: Well, basically it started out as a very simple data link protocol. Data link is the second layer of the OSI model. OSI stands for Open Systems Interconnection; it’s the computer communications protocol stack. You have the physical layer and then the data link layer and a bunch of other layers all the way up to the application layer. SpaceWire defines a very simple data link layer protocol. It’s so simple, in fact, it’s easy to design and easy to get up and working. But when you start using it in a system, you quickly run into problems because we don’t know what information we’re communicating over the link. You have to define all of the various layers on top of it. What we’ve done, and what I’ve helped to do, is define the upper layer portions of the protocol to work with SpaceWire.
One of the first things we did was something very simple; in commercial industry, when you look at Ethernet, they do it too. We basically just stole ideas from other standards. We introduced the concept of Protocol ID so that we then knew what information we were passing over the link versus having to write interface control documents and defining packet formats and what’s in those things. On a spacecraft to spacecraft basis, we decided to try and define entered protocols and a method for identifying those protocols over SpaceWire. We introduced the Protocol ID in a standard packet format so we could then start developing protocols.
What we did after that is we introduced the WiFi, so the SpaceWire community developed various services to put over the network, services such as memory service so that you could read or write memory at the address basis like PCI does. PCI is a standard bus interface used in all the computers, and it defines memory mapping so that boards can communicate with each other in its memory mapped way. Basically, what we did with SpaceWire is we defined a memory map protocol called Remote Memory Map Protocol – the acronym is RMAP – and it just basically is a memory map protocol over a serial bus, like SpaceWire. You can actually use it over any serial bus. We developed it to use with SpaceWire, but it doesn’t have to work with SpaceWire.
So, we developed that protocol, then we developed another protocol to help out with quality of service. Quality of service has to do with the quality of service of the bus. It can deal with reliability; it can also deal with latency; those types of issues. The quality of service that we were attempting to solve was the retransmission reliability aspect, so if you lose a packet in transit you can recover it through acknowledgements, or timeouts and retransmission, etc. So, we developed that protocol called Reliable Data Delivery Protocol, or RDDP. We developed that with GOES-R in mind, and we made it generic enough so that we could standardize it and others could use it.
As we go up the protocol stack, we want things to be plug-and-play, so we’re putting the hooks into SpaceWire to support plug-and-play. We’re working with AFRL – the Air Force Research Laboratory – out in Albuquerque, New Mexico, who’s working with Operational Responsive Space, or ORS, in trying to develop satellites which they can integrate in a week, from development to launch, based on having standard, off-the-shelf components and having analysis tools to plug in mission requirements and flow down a master equipment list that they can use to stockpile components and just plug them together. We worked with them and ESA and US industries as well to supply a plug-and-play protocol for SpaceWire.
When I say plug-and-play for SpaceWire, I mean making SpaceWire able to support plug-and-play. Basically what we did was we defined the protocol and a protocol ID that we use for all our other protocols for a method for doing network mapping and device discovery. Included in that is change-of-status indication so that if something changes on the network, there’s an indication to the host through the network master…or masters, it could be multiple. They’re notified asynchronously, very quickly, so they can go out and remap it and figure out what’s changed. That’s the third protocol we developed, and that one is still in the process of being defined. We’re fairly far along with it, and the Air Force Research Labs is doing a technology demonstration satellite, called a TacSat – I can’t remember the number of it – but they call it “Plug-and-Play Sat,” or PnPSat, which is actually emulating the protocol that we developed, the SpaceWire plug-and-play protocol. They’ve actually gone beyond that and defined the upper layers and a lot of other things above SpaceWire that are in the plug-and-play world that are kind of bus-independent.
We’re also working with something called space fiber, which is a fiber optic data bus that is compatible with SpaceWire. It’s distinct and independent from SpaceWire, but it’s also made to be the hook-in to SpaceWire and to take slower SpaceWire links. SpaceWire is typically on the order of 200 Mb/sec, roughly, and we wanted a data bus that has gigabit performance, so basically space fiber is a fiber optic data bus, and we can take SpaceWire links and multiplex them down a single space fiber, and vice versa, break out those links from a single space fiber into multiple SpaceWires. It also helps solve some of our quality of service issues because we’re dealing with frames versus packet links, which could be infinite or not defined. So we’re defining right now, with ESA, SpaceWire quality of service. We did it to the one protocol, which kind of takes care of a certain aspect of quality of service, and we’re trying to address it in more of a global sense, with scheduling and all kinds of other concepts.
Anyway, space fiber is a new development and we’re prototyping that right now with ESA. ESA has prototyped it; we’re prototyping it now, and we’re going to demonstrate it on a test flight called Max Launch Abort System. It’s an alternative launch aboard system for the new Orion vehicle, which is NASA’s new crewed vehicle that will replace the Shuttle and get us back to the Space Station and to the Moon. So we are going to do a test flight demonstration of space fiber taking SpaceWire links – four SpaceWire links – which are basically hooked up to some commercial cameras that we converted from Ethernet to SpaceWire, and multiplex those four down to a single space fiber. We then take that output and we drive an RF transmitter, which downlinks it to the ground where we recreate the images on the ground. It’s just a simple test flight to demonstrate and test the set out, so we’re working on that theory as well.
NTB: In 2006, Goddard’s IPP office began actively marketing SpaceWire to the aerospace industry, resulting in Space Act Agreements with several companies to develop and produce viable products. How has that effort been going?
Rakow: Well, we have a bunch of companies that we’ve been working with to develop SpaceWire designs in radiation tolerant devices. ASICs, specifically. We’re working very closely with BAE Systems and they’ve made a SpaceWire ASIC; they’re in the process of integrating it into two of their designs.
The first thing we did with them was a SpaceWire ASIC, which is being used on GOES-R, and also being used on LRO – the Lunar Reconnaissance Orbiter. It’s going to be used on the GPM mission, which is the Global Precipitation Measurement mission. It’s also being used on LCROSS (Lunar Crater Observation and Sensing Satellite), which is just a knockoff of LRO; it’s the same architecture. Basically, they took that ASIC after we developed it with them and they put it onto their single board computer, the RAD750 with the radiation hardened version of the PowerPC 750 computer chip.
The next generation part they’re making is a bridge chip. They’re integrating the SpaceWire design into the bridge chip, which is the main component on their single board computers, tying the processor chip 750 into the memory and all the peripherals. That ASIC’s called the Golden Gate ASIC.
They’re also integrating it into another ASIC, their RAD6000 system-on-chip. Basically, before the RAD750, the RAD6000 was their main processor. It’s not as high-performance as the RAD750, but it’s still a very capable machine. What they did is, they’re integrating it into a system-on-chip where you have a single die, a single ASIC, which has the processor, the memory, everything on it. SpaceWire’s going to be integrated into that RAD6000 system-on-chip design, which will be a nice product for a lot of embedded applications.
Then we worked with Honeywell; they’ve made an ASIC out of it for a NRO – National Reconnaissance Office – project through Lockheed Martin Sunnyvale. They made an ASIC with a big bar link on it – I think it goes 16 links – and it’s kind of an optimized design for their specific application. But they did have a design where they took our SpaceWire link and they put, like, 16 of them and they had a backend bus to the RapidIO, which is kind of a high-speed bus, very similar to what we’re doing with space fiber.
And we’ve worked with Aeroflex; they’ve made an ASIC. It’s not exactly our design; we provided them with a design and they took a lot of the features and ideas from it and they’re making a router ASIC, or a switch, out of it. They had another ASIC, a system-on-chip, which they took a SpaceWire design from a Swedish company and made an ASIC out of it, but that doesn’t use our design. They’re making another router, a switch design that has a lot of the features of our ASIC.
We have that, and then I have an SBIR – Small Business Innovation Research – where we’re making a SpaceWire switch design with our design as well.
NTB: Looking ahead, what types of future applications do you envision for SpaceWire technology?
Rakow: Basically I see it being used to replace parallel buses like PCI. PCI Express is a serial data interface, and we see SpaceWire as being a good application for serial backplanes. They’re using it in some places on Orion for the serial backplane. You can see Harris Corporation, down in Melbourne, is doing some SDR work – software defined radios – where they’re using SpaceWire in RMAP as kind of a serial backplane.
We see it as very useful for serial backplane applications and for robotic missions that don’t require isolation – galvanic isolation – because SpaceWire doesn’t support that. So, robotic missions that don’t require galvanic isolation, and for serial backplanes, we see it as being a very strong case for its use in space mission applications.