I had the distinct honor of working for John Muratore on two distinct projects. One was the X-38. But before that, I worked on developing advanced software for his Real Time Data System project.
The RTDS project started in 1986 when Muratore saw the archaic structure of Mission Control. The primary goal of the project was to transition from a single mainframe computer that drove dumb terminal displays at Mission Control consoles to a distributed system comprising many minicomputers and data servers, each of which ran their own sets of software, that displayed data to users on non-dumb terminals, and that published data to / subscribed data from other applications. The project took off in part because it had the explicit backing of Eugene Kranz.
One challenge was the completely fractured nature of computing at that time. Organic Marble's answer has a graphic that claimed "RTDS will run on almost any UNIX workstation". That made me chuckle.
This was the age of the minicomputer. Nothing was standardized. UNIX had not yet been standardized. The UNIX library calls never were the same from one vendor to the next. The C programming language had not yet been standardized. Every vendor provided its own compiler that had its own interpretation of what C was, and had its own library of standard functions that were anything but standard. The manner in which computers stored and transmitted data had not been standardized. Consider the 32 bit hexadecimal number 0x12345678. Some computers would store this just like that (little endian). Others, would store that number as if it were 0x87654321 (big endian). Yet others, as if it were 0x78563412 (mixed endian). Back then one had to expect every random order when switching to a different computer.
The reason RTDS "ran on almost any UNIX workstation" was because John continuously wrangled with vendors to supply the project with "free" computers for short trial periods. We had to be agile well before the concept was known elsewhere. But this also made our code get bloated with
#if defined computer_X do_this #elif defined computer_Y do_that ... constructs because every computer was different back then.
My contribution to the project was in the form of AI software than did not use expert systems. I had been charged with identifying opportunities for using AI in Mission Control, but they didn't need me to recommend expert systems. NASA already knew about that. I focused on signal processing and pattern recognition. One system identified what electrical devices had been turned on or off based on transient signatures. My software could easily detect when the cabin fan properly turned on or off, when someone had flushed the properly functioning toilet, when someone powered up the properly functioning vacuum cleaner, or turned on or off a properly functioning scientific experiment. But it had less success if the equipment was malfunctioning. So that was a failed idea.
But I did have one key success. Extended Duration Orbiter (EDO) missions used a Rube Goldberg device called the Regenerative CO2 Removal System to remove carbon dioxide from the cabin atmosphere. The device went through a ridiculously complex sequence of operations that over the course of time accumulated carbon dioxide from the cabin atmosphere and later vented that CO2 to vacuum. There was a chance of a very bad failure at several key points in this ridiculously complex sequence of operations where cabin atmosphere instead of accumulated CO2 could have been vented to vacuum.
The RCRS had built-in failure detection software that looked for these failure modes. In the case that anything suspect happened, the RCRS placed all of its valves in safe mode, and then erased all of its memory. If the machine did shut itself down, there was no way to query the machine regarding why it did so. With multiple failure points, diagnosing why the machine had shut itself down would have been challenging.
The machine did not send internal state information, but it did send sensor readings. I was tasked with writing a pattern recognition application that made sense of these limited data. My app ran silently for several EDO flights. Years later, in 1998 (STS-90), it pinged loudly, a few seconds before the machine shut itself down.
My application saved Mission Controllers eight hours of diagnosis time. My application most certainly did not suggest the brilliant solution they came up with. It simply told them "the device failed HERE". They quickly verified that that diagnosis was correct. And then they went to work coming up with a way around the problem.
The so-called "Shuttle Flight Data File" included, amongst other non-booklike things, multiple rolls of duct tape. The arrived-at solution used that duct tape.