Posted on 01/23/2004 1:39:26 PM PST by Keith
Sounds like they used Windoze CE for Embeddeds.
The rover itself (that is to say, the one on Mars) is unique in that it had to be fashioned, assembled and prepared for launch in a clean room with sterilization techniques from cradle-to-grave so as to assure no terran-based microbial contamination of Mars.
But yes, there is a terran copy. It is the testbed by which all software updates are sent for quality assurance.
Well, they can talk to the spacecraft and get data back. Albeit S-L-O-W-L-Y -- the mission isn't dead by any means, just in super panic mode. I've been in JPL many times when crises like these emerge. What will happen is a very TINY team of experts will be in charge (they were most likely the same group of people whose input was ignored for many of the development/testing). These people, most familiar with the project and the least listened to, will turn out to be the ones that will save the day. But at 120 bits/sec it will take quite some time to get meaningful data back.
Then around 1994 or so I went to work for a company putting control systems in railyards. A start-up subsidy of a bigger company. A few weeks before I came on board they had gotten there first major system operational for a major US railroad. It worked very well. The customer loved it. But they had almost been kicked out, under extreme prejudice, too!
They used a real-time unix-like OS. QNX. They had hired -- what we now call out-sourcing -- an "expert" to write the software, to port their prototype system into QNX. The consultant delivered the binaries, the source, all with the very development system itself he had used, that he been loaned. The company then took the binaries to the railyard, installing the system on site, a tight schedule, the yard was to go big time VIP "ribbon-cutting" the next week. The software worked, but after a couple of days it started going haywire. The system kept freezing up and rebooting somewhat randomly, after anywhere for three to fifteen minutes of operation.
For days they burnt the midnight oil trying to figure out what the problem was -- replacing system boards, IO modules, etc. The software had been working so they assumed a faulty hardware component.
Back at the home office, the chief engineer tried to rebuild the software system that had been delivered by the consultant, recompiling everything from source. Part of an attempt to add debug checkpoints -- something, anything to help identify the problem.
His rebuild failed. The customer became incensed -- they had until Monday morning to get the system working -- it was then Friday late-day. Or they would be out. And lose their big customer. And be sued for whatever a bankruptcy would leave, etc.
The chief engineer worked desperately over the weekend. His rebuild of the software had failed because of some unresolved externals. That could only mean not all of the software source had been delivered. But the consultant kept saying they had everything they needed. When they were able to reach him He was out more than in.
The chief engineer decided he see if maybe the missing software had been inadvertantly deleted. It happens. Honest mistakes happen all the time. He ran a disk sector-scanner search looking for the missing externals.
He did find some deleted sectors and painstakingly read through each of them. It was Saturady evening. He had found the missing source module -- the header made it clear. But as he read on he made a surpising and troubling discovery.
The missing and deleted source file had some intriguing comments. They talkedg about placing a "bomb" in the code.
As he looked the code over he saw he was looking at a very sophisticated randomly triggering bomb that buried itself in the QNX operating systems kernel -- that mangled some process scheduling tables that even few QNX experts know about. Amazingly the comments were unambiguous as to the malicious intent of the code. Vanity, oh vanity! Pride of waorkmanship, perverted ...
The big company headquarters was contacted. The findings explained, the dire circumstances on-site with the important and vital customer made clear. On early Sunday morning three company lawyers flew in. They met briefly with the chief engineer and the subsidy's director.
The lawyers then drew up some serious paperwork, and drove over to the consultant's house. They woke him up. They read him the riot act, and told him "Here is what you will do". His alternative? A few federal felonies, and a civil suit that would ruin him, when his jail time finished.
That afternoon he flew to the railyard and in a short while had the system working, sans his software bomb. The chief engineer stood over his shoulder the whole time his hand were near a keyboard.
The lawyers had insisted the consultant tell them why he put the "bomb" in "To make sure I get paid" he told them.
They paid him his travel expenses. And they paid on the contract he had. And left it at that.
Me? I would have pressed the case for criminal charges against him. But then I could have un-did the bomb with or without his help. But at the time -- that desperate time -- the company needed the fix made. Without the blackmail bomb removed they could not suvive -- they needed that project's success they needed to be in the good graces of that major railroad. Despite the fact that it was blackmail, they had to deal with the blakmailing consultant.
* * *
I do not think this martian rover is such a case -- that is I hope not. The management controls, are theoretically orders of magnitude better than the Monster Garage-type management that freight railyard control systems get.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.