Next installment: Backtracking a bit. I mentioned previously that I joined the SPACEHAB program while the merger of Boeing and McDonnell-Douglas was under way. The business systems had not been transitioned to Boeing yet, the result being that I was of the last employees to be assigned a McDonnell-Douglas clock number, in addition to my Boeing employee number. We were entering our daily time charges by telnetting into an old mainframe application. That only lasted a few months before we were moved over to the Boeing timekeeping system.
I was assigned to the software group, along with Bob Robinson, Margaret Wood, and Dean Hallmark; we also had Mark Mumbleau, an engineer at the SPPF who was the liason and test lead for our group. Tim Tripp was our manager. A few months after I started, Tim was promoted to engineering manager for the program, and Steve Noojin, an engineer from the thermal group, was assigned as our manager. Steve didn't know a lot about software, but he was a good manager and we trained him right.
Now, I promised to say something about the Experiment Data System. It was a pretty cool system. Its purpose was to gather up telemetry from the RDM
payloads, route them through the Shuttle and NASA comm systems, and get it distribute to the right experimenter groups at the Mission Control Center (more about which later). Previous systems for interfacing payloads, such as the Shuttle's Payload Data Interleaver and the Spacelab data systems, relied on these synchronous serial interfaces that required special hardware to interface to, and were very timing-sensitive. The EDS, on the other hand, allowed experiments to interface using ordinary Ethernet and TCP/IP protocols. There was an Ethernet network on board the RDM
that payloads could plug into. The EDS hardware pieces consisted of:
* The EDS Main Unit, or EDSMU. This was the brains of the onboard half of the system. It handled all of the data management and routing; it buffered up data when downlink channels were not available, and it controlled the other onboard elements of the EDS. It actually contained two redundant units -- there was an A and a B side, each independent except for a few bits of the comm interfaces. Only one side or the other could be powered at a given time, and this was selectable via a switch on the front panel. If the A side failed in flight, the crew could move the switch to the B position, and we could keep operating.
The EDSMU interfaced to the onboard Ethernet. A payload connected to the system by opening a TCP socket to a port number on the EDSMU that we assigned them. After that, all it had to do was write telemetry data to the socket, and that data would come out on the ground side of the system. Similarly, the ground end could send commands (if enabled) to the payload by writing data to the ground end, and when it got onboard, the EDSMU would spit it out of that same port. The EDSMU also provided some standard RS
-232 and 422 ports that payloads could use as an alternative to the Ethernet; several payloads (mostly older hardware) used these.
The EDSMU also had the job of recording any data sent for downlink when the downlink channel wasn't available. As you might know, the Shuttle was not in contact with the ground all of the time; most of the time there was a minimum period of about 10 minutes, over the Indian Ocean, where there was no TDRS
satellite in range and so comm would be lost during this period. Additionally, for comm channnels which use the Shuttle's Ku-band system, availability was subject to the pointing geometry limitations of the dish antenna, which was a very complex problem. The MCC
issued predict times for each orbit for when various comm systems would be available or unavailable. We built timeline files which we sent to the EDSMU to tell it when it needed to record data and when it could downlink in real time. Payloads were none the wiser; they sent data to the EDSMU and whether the EDSMU downlinked in real time or recorded it was transparent to them. Once every 12 hours or so, we dumped all of the recorded data to be processed on the ground. Recording was done to a hard disk in the EDSMU, which was semi-revolutionary at the time, and a huge improvement over the tape-based systems that Spacelab and the Shuttle itself used.
* The EDS-HUB was the hub of the onboard Ethernet. It actually contained hubs for two networks, a 10baseT network and a 100baseT network; these were cross-strapped to form one logical network. The 10baseT side provided 22 physical ports for payload use; the 100baseT provided 11. Physical connection was made by a variety of methods; for most payloads, the twisted pair went to one of the typical Amphenol locking circular connectors, which were available at various places in the module. There were also some spares which were coiled and stowed under the floor. Also, the forward and aft bulkheads each had a panel with five standard RJ
-45 jacks, all of which were connected to the 10baseT half of the network. These could be used to connect payloads, but could also be used on an as-needed basis with the Shuttle crew laptops. We did actually wind up doing this once during STS
In addition, the hub distributed timing signals from the Shuttle Master Timing Unit. There were three signals available: GMT and MET time, both in IRIG-B format, and a 1024-khz square wave. The hub provided 12 outputs for each. The hub also provided the GMT and MET signals to the EDSMU, which synchronized its internal time to them; the EDSMU then provided GMT to the Ethernet-connected payloads via Network Time Protocol (NTP).
* The Experiment Interface Unit (EIU) provided additional types of interfaces to payloads that couldn't interface with an Ethernet or a serial interface. The EIU was a small processor box that installed adjacent to the payload that was using it, and interfaced with the EDSMU via the Ethernet. The original idea was that an EIU would be loaded with interface hardware on a mission-specific basis; IIRC there were four slots available in the chassis for interface boards. The original list of offered interfaces included:
-- Discrete (on/off) inputs and outputs. The discrete inputs accepted 0V as "off" and 5V or above as "on"; they were zener-protected against out-of-range voltages. Sampling rates of up to 100 Hz were available. For the outputs, there was a choice of an open-collector logic output, which could be pulled up to 5V or 12V or left open as required, or a dry-contact relay.
-- Analog inputs and outputs. The analog inputs could be configured for 8-bit or 16-bit operation, with sampling rates up to 100 Hz. Several gain setting values were available, and like the discrete inputs, they were zener protected. The analog outputs were configurable for 0 to 10V, -5 to +5V, or -10V to +10V, and were all 16-bit.
-- RS232 serial. Two ports were available on each EIU.
-- Emulation of the Spacelab High Rate Multiplexor (HRM) interface. This was basically an externally clocked (separate clock and data), high-speed serial interface. Our interface could provide the clock if needed, at the same rates that were available on the real HRM, up to 48 MHz. We could also provide a periodic "format" (clear to send) pulse for payloads that needed it, although unlike the real HRM, our emulation was timing-insensitive and would accept data at any time. This was an input-only interface.
-- Emulation of the Spacelab Remote Acquisition Unit (RAU) interface. This was a two-way, medium-speed synchronous serial interface. As it turned out, none of the STS
-107 payload customers ordered this, so when we ran into problems with the implementation that would have required a major hardware change, this was abandoned.
-- Emulation of the ISS MIL-STD-1553 payload bus. This was not ordered for STS
-107, but we did have a customer who wanted it for the planned second flight of the RDM
. I was working on the software for it at the time that STS
-107 flew, and it was basically working although it had not been tested for conformance to the ISS interface spec.
The EIU was packaged into a rather odd-looking box that was wedge-shaped at one end. The purpose for that was to be able to fit into a small space at the bottom of a payload rack, where it fit up against the curvature of the exterior wall at the floor level. The wedge end provided clearance for the curved surface. The EIU could also be mounted on either the front or the rear bulkhead. The EDSMU could accommodate interfaces for up to eight EIUs at a time.
The ground half of the system consisted of two units:
* The Experiment Ground Data Assembly (EGDA) was the equivalent of the EDSMU and EDS-HUB on the ground system. It interfaced with the comm interfaces in the MCC
to receive the downlink data and send commands. It contained a processing unit which was sort of the mirror image of the EDSMU; what the EDSMU packaged up, the EGDA unpacked, and vice versa. The EGDA connected to the payload user network in the MCC
. Experimenters brought in their own equipment which they connected to the net; we then gave them a TCP port number to open a socket to at the EGDA, and through that socket they received anything that the payload sent to the EDSMU socket onboard. And the EGDA, like the EDSMU, also offered RS
-232 and RS
-422 ports as an alternate means of connection.
The EGDA had two other major jobs. When we dumped recorded data from the EDSMU, it was the EGDA's job to capture the dump, separate the individual payload data streams, and make them available to the payload users. We did this via an FTP service; each payload's data was compiled in a file which was moved to an FTP account for that payload.. Each payload had a user ID
and password that they used to FTP the data from the EGDA to their equipment.
The other major job was controlling access to payload commanding. Shuttle missions were pretty carefully planned as to what would happen when; there are all sorts of ways that one payload's operations can interfere with other payloads, or with work that the astronauts are doing. Additionally, one of the command channels had very limited bandwidth, and we had to coordinate the use of it with a secondary program that was also on the STS
-107 flight. So we could only allow payload users to send commands to their payloads when authorized. We had two mechanisms for enforcing this: we could enable and disable commanding on a per-port basic, and we could also turn the uplink channel interfaces on and off. The EGDA implemented all of this.
* The EDS Management Interface, or EDSMI, was our console for controlling the whole EDS system. This was an ordinary PC
, unlike the other components of the system which were custom assemblies. During the mission planning process, it allowed us to define which payloads were on the flight, which ports and IP addresses they would use, how much bandwidth they would be allowed to use, etc. During the flight, it presented us with a big window that displayed several panes of information. At the top were rows of icons, each representing a payload port. It showed us if the port was enabled, if the payload had a socket connection to it, and the bandwidth being used. Further down, we had a corresponding row of icons representing the experimenter groups' ground equipment. These icons showed us if they were connected, if they were enabled for commanding, and the bandwidth in use. In between the top and bottom panes were a row of icons representing the space-to-ground communications channels; it showed us the routing status of each channel and the bandwidth being used on each channel. There was also an icon showing the onboard data recording disk drive; it showed us the rate at which data was being recorded, and the amount of recording time remaining at the current rate. Over on the right side was a list of internal EDSMU and EIU parameters and the current value of each.
Underneath the row of icons representing the ground equipment, we had a window that graphically represented the availability times of each of the downlink channels, and when recording would take place; a moving bar on this window represented the current time, and each state-change icon on the future side of the bar had a countdown timer showing how long until that event took place. At the very bottom, we had a text window that showed us caution, warning, and advisory messages from the various system elements. We also had a command window that we could open if we needed to send a command to the EDSMU, EGDA, or an EIU. And there were some secondary windows that went with other specific functions. The EDSMI interfaced to the EGDA via a protected port on the Ethernet.
Of the quantities of hardware built:
Three EDSMUs were built, numbered 000, 001, and 002. #001 was designated the flight EDSMU; this was the one actually installed in the RDM
. #002 had been used for qualification testing, during which it was subject to mechanical stresses beyond the flight limits, so it was judged not suitable for flight, although it could have flown in a pinch. We used it at the SPPF during the payload integration process for "out of module" testing, in which the payload would test its data and command interfaces on the bench prior to installation in the RDM
. #000 was the engineering unit; it was functionally and electrically equivalent to the other two, but was not mechanically constructed to flight standards. It stayed in the development lab in Huntsville.
Three EDS-HUBs were built, also numbered 000, 001, and 002. Similar to the EDSMU, #002 had been used for qual testing and was assigned to out-of-module payload integration. #001 was the flight unit. Boeing never took delivery of #000; it remained at the subcontractor's site in Colorado throughout the program. It is my understanding that it never worked right, although I never worked with myself.
Four EGDAs were built, numbered 001, 002, 003, and 004. 001 and 003 were at the SPPF; #003 was assigned to work with the out-of-module string of bench equipment, and #001 interfaced with the in-module equipment. #002 was assigned to the development lab in Huntsville. #004 was not finished until shortly before the STS
-107 flight and was never used very much. #001 and #003 were sent to Houston to be used in the MCC
for the flight. We had intended to use #001 as the primary for the flight, but a connector broke on it during pre-launch testing, and although it was repaired before launch, #003 became primary because I had more confidence in that one. As it happened, we wound up having to use both during the flight, something I'll get to in a later installment.
Six EIUs were built. There was an qual unit, numbered #001; it spent some time in the development lab in Huntsville, and then was sent to the SPPF for mechanical checkout of the various mounting options. It had gotten damaged during qual testing and had to be sent back to the subcontractor for a while. After that, it was used with the out-of-module payload testing string. An engineering unit, #000, stayed in Huntsville; like the #000 EDSMU, it was not mechanically constructed to flight standards. We eventually wound up taking all the boards out of it and installing them in a commercial chassis, because it was easier to work with that way, and it allowed us to install a disk drive for development purposes. (The EIU design did not incorporate a disk drive; all storage was in flash memory.) Four production flight EIUs were built, numbered 101, 102, 103, and 104. #103 had fan problems and had to go back to the subcontractor for repairs; as the STS
-107 configuration only required three EIUs, #103 was not assigned to the flight and was put into storage when it came back to the SPPF.
We didn't assign serial numbers to the EDSMIs, but basically there were four. Two were at the SPPF; one was in Huntsville. One was sent to the MCC
, where it was intended to remain in storage in between RDM
Phew... that's a lot of info. Next time I'll talk about some of the development of the EDS system.