PBS's "Nova" and MER

In article ,
Grant Goodes writes:
(Henry Spencer) writes:
The alternative is to insist that the software must be officially finished
before launch, while privately conceding that it may have to be fixed up
afterward because of the tight schedule; this does not actually strike me
as an improvement on letting the developers do the job right once.

Every onboard SW project I've ever worked on (admitedly only one that
actually flew, but several orphans as well) has taken that line, at
least officially: SW must be "done" before launch. In practice, the
Oersted satellite would have been space-scrap if we hadn't designed
in the ability to upload permanent patches.

I concur with the viewpoint that SW is best kept as HW's child, rather
than sibling (and I speak as an electrical engineer).

Well, _There's a surprise!

Design the HW
the best you can, freeze it as early as you can (of course after testing),
but accept that meaningful SW development cannot really commence until
the HW exists (or is at least mostly spec'ed out). The SW guys will do
a better job if they're designing it to real HW, but that does mean they
do their job uncomfortably close to the lanuch deadline, and may not
even be done then. Just make sure that the functional kernel of the
SW (including a safe and robust patch mechanism with fall-backs) works
well; but other stuff can be fixed on the fly.

Very good points, Grant. But if a may impose a bit of the "Enemies"
point of view, could we prehaps restring the process definition to
include "Hardware spec'ed and designed with input from the guys who
actually are going to have to program the bloody thing."

If I had a dollar for every time I've had to work around the result of
the hardware designer's implementation of a "feature" that, despite
the best intentions of the designers, instead of improving the
system's utility, made it another damned thing to work around...
And of course, by the time it was pointed out, and convincingly
presented, it was too late to change th hradware.

Now, I'll grant that _Good_ people for this type of stuff. (Embedded,
Real time control, Data Acq, u.s.w.) are hard to come by, but the
projects that I've done that have had the most success have had at
least some input from teh programming side from the very beginning.
But then, you need somebody who understands the depths that the
software/firmware's going to have to plumb, and who, can at least
read and speak Hardware enough to understand what they're seeing, and
make cogent comments.


--
Pete Stickney
A strong conviction that something must be done is the parent of many
bad measures. -- Daniel Webster

"Pat Flannery" wrote in message
...
the software that remained to be written concerned the rovers ability to
navigate on the surface; _not_ the landing phase,

Be kinda pointless to fix landing software for Spirit now, eh?
--
If you have had problems with Illinois Student Assistance Commission (ISAC),
please contact shredder at bellsouth dot net. There may be a class-action
lawsuit
in the works.

(Peter Stickney) writes:
In article ,
Grant Goodes writes:
I concur with the viewpoint that SW is best kept as HW's child, rather
than sibling (and I speak as an electrical engineer).

Well, _There's a surprise!

That didn't come out right: I'm _educated_ as an Electrical Eng., but
have worked mostly in embedded compilers/kernels and embedded SW development,
and when I placed SW as HW's child, I was specifically addressing the
issue of development cycle, and why SW development (in my opinion) should
proceed _chronologically_ somewhat after HW developmnet. I'm definitely
NOT saying that SW considerations are in any way secondary to HW. Au
contraire!

Very good points, Grant. But if a may impose a bit of the "Enemies"
point of view, could we prehaps restring the process definition to
include "Hardware spec'ed and designed with input from the guys who
actually are going to have to program the bloody thing."

If I had a dollar for every time I've had to work around the result of
the hardware designer's implementation of a "feature" that, despite
the best intentions of the designers, instead of improving the
system's utility, made it another damned thing to work around...
And of course, by the time it was pointed out, and convincingly
presented, it was too late to change th hradware.

We have met the enemy, and he is us! I completely aggree that input
from SW is _crucial_ to effective HW design (and not just in onboard
space systems): Alas, it is rarely given any credence, since HW people
tend to assume that SW people "just don't get it" (even when they have
engineering degrees, like I do). Unfortunately, much of HW design for
space systems is driven by issues like rad-hardening, power-budget,
cost, and trying to re-use well-understood designs from the past. The
fact that the SW has to be written by Houdini to actually get the HW
to _do_ anything doesn't even make the radar screen.

I made _considerable_ efforts to effect changes in the Oersted HW design
to ensure that SW would be more effective (especially considering that
there was only 128K/128K of code/data RAM), but were it not for the presence
of a single "good" HW engineer on the team who snuck changes in through
the back-door (thanks Neils!), most of my efforts would have been in vain.

Now, I'll grant that _Good_ people for this type of stuff. (Embedded,
Real time control, Data Acq, u.s.w.) are hard to come by, but the
projects that I've done that have had the most success have had at
least some input from teh programming side from the very beginning.
But then, you need somebody who understands the depths that the
software/firmware's going to have to plumb, and who, can at least
read and speak Hardware enough to understand what they're seeing, and
make cogent comments.

I've made a very interesting but promotionally-challenged career out of
being the poor suckah that understands both the HW and SW sides of the
design, and fights to make the two form a functional if uncomfortable marriage.
There's a reason why _good_ people for this kind of stuff are scarce: It
doesn't get you recognized as a valuable asset to the team, since you
challenge sacred cows on both sides of the HW/SW divide.

grant..

In article ,
Grant Goodes writes:
(Peter Stickney) writes:
In article ,
Grant Goodes writes:
I concur with the viewpoint that SW is best kept as HW's child, rather
than sibling (and I speak as an electrical engineer).

Well, _There's a surprise!

That didn't come out right: I'm _educated_ as an Electrical Eng., but
have worked mostly in embedded compilers/kernels and embedded SW development,
and when I placed SW as HW's child, I was specifically addressing the
issue of development cycle, and why SW development (in my opinion) should
proceed _chronologically_ somewhat after HW developmnet. I'm definitely
NOT saying that SW considerations are in any way secondary to HW. Au
contraire!

Well, why didn't you _say_ so!
In that case, I agree.

We have met the enemy, and he is us! I completely aggree that input
from SW is _crucial_ to effective HW design (and not just in onboard
space systems): Alas, it is rarely given any credence, since HW people
tend to assume that SW people "just don't get it" (even when they have
engineering degrees, like I do). Unfortunately, much of HW design for
space systems is driven by issues like rad-hardening, power-budget,
cost, and trying to re-use well-understood designs from the past. The
fact that the SW has to be written by Houdini to actually get the HW
to _do_ anything doesn't even make the radar screen.

But, I must say, in jumping on that particular hobbyhorse, that I've
spent a brace of decades having had to pound on various
hardware-designing EEs that just becase they can whack out a 10-line
toy driver, coding is _not_ a simple process.

One of my happier moments at the World's Largest Battery Manufacturer,
was during a conference with a fellow concerning the design of a new
Battery Test System. (Mondo serious Real Time Control Data Acq, and
Data Integrity issues - picture modelling the sub-microsecond load
state changes of 1,000 GSM phones at once, pulling in data at rates up
to 1 MHz.) He'd done an earlier system for us, as was damned good, but
he really didn't get the scope of things until he asked to see a
listing. 300,000 lines of code on A-size sheets was a bit more than
he expected.

I've made a very interesting but promotionally-challenged career out of
being the poor suckah that understands both the HW and SW sides of the
design, and fights to make the two form a functional if uncomfortable marriage.
There's a reason why _good_ people for this kind of stuff are scarce: It
doesn't get you recognized as a valuable asset to the team, since you
challenge sacred cows on both sides of the HW/SW divide.

It also seems to be a difficult thing to teach, especially in this day
& age. Perhaps unfortunately, the rapid growth in performance, and
the decreases in cost, in the "consumer" sides of computing have
allowed Egregious Software Bloat to become the norm. When even a
driver won't fit on a 3.5" floppy...

Kids these days! When I started in Microprossers, we had Intel
4004s. With 256 Bytes of memory. And we were Damned Glad to Get them!

And we had to eat dirt. And there wasn't any air.
(Henry Spencer was around, though)

--
Pete Stickney
A strong conviction that something must be done is the parent of many
bad measures. -- Daniel Webster

(Peter Stickney) writes:
Kids these days! When I started in Microprossers, we had Intel
4004s. With 256 Bytes of memory. And we were Damned Glad to Get them!

I'm a firm believer that "kids these days" should _still_ be taught
low-level programming on such a system. No god-damned SDE's, no
mouse, no *display* for that matter (though I might give the little
*******s a single hex-digit LED). You can learn an awful lot about
programming by working with a truly constrained system.

And we had to eat dirt. And there wasn't any air.
(Henry Spencer was around, though)

Well, most kids eat dirt at some point, but I think all
the living ones had air throughout most of their lives.

grant..

Peter Stickney wrote:

In article ,
Grant Goodes writes:


I've made a very interesting but promotionally-challenged career out of
being the poor suckah that understands both the HW and SW sides of the
design, and fights to make the two form a functional if uncomfortable marriage.
There's a reason why _good_ people for this kind of stuff are scarce: It
doesn't get you recognized as a valuable asset to the team, since you
challenge sacred cows on both sides of the HW/SW divide.


It also seems to be a difficult thing to teach, especially in this day
& age. Perhaps unfortunately, the rapid growth in performance, and
the decreases in cost, in the "consumer" sides of computing have
allowed Egregious Software Bloat to become the norm. When even a
driver won't fit on a 3.5" floppy...


For space-project programmers, you really need people who are
aerospace engineers with computer programming skills, as opposed to
computer programmers that go into aerospace. Not necessarily by
training, but certainly by orientation. The skills set and mind set
required to do large consumer code projects are significantly different
than embedded systems, even if the language is the same. Not a value
judgement, but an observation from experience on all sides of this fence
(H/W engineering- flight operations - flight S/W programming -
guidance & navigation design engineering, with technical supervision
during each). Some programmers out of school "get it", and a whole lot
of others don't. The percentage who don't has gone up astronomically in
the last 10 years as programming has grown as a profession. What they
teach in schools *does not* seem to translate well into capable and
properly oriented aerospace programmers. I have to assume they know how
to do consumer software, but I couldn't say.

Brett

In article ,
Gene DiGennaro wrote:
...One of the reasons why the
great unmanned missions of the 70's and early 80's were less likely to
fail was because NASA threw gobs of development money at them...

Unfortunately, the data does not support the "less likely to fail" part.
Those missions had failures, both total and partial. The failure rate has
not actually increased very much, if at all; it's just that the failures
of the 70s and 80s are forgotten, while the failures of today are still
fresh. There is also a tendency to ignore some of today's less prominent
successes. The 70s and 80s look like a golden age of near-total success
only by quite selective memory and the accident of which category a few
highly visible missions fell in.

It's also worth remembering that the great unmanned missions were becoming
*very* prone to another form of failu cancellation before flight. The
switch to smaller ones was not a sudden aberration, but a recognition of
political reality. Galileo and Cassini both had repeated near-death
experiences -- the presence of Huygens is probably the only thing that
saved Cassini -- and several other large missions did die, e.g. Cassini's
sister CRAF.
--
MOST launched 30 June; science observations running | Henry Spencer
since Oct; first surprises seen; papers pending. |

In article ,
Grant Goodes writes:
(Peter Stickney) writes:
Kids these days! When I started in Microprossers, we had Intel
4004s. With 256 Bytes of memory. And we were Damned Glad to Get them!

I'm a firm believer that "kids these days" should _still_ be taught
low-level programming on such a system. No god-damned SDE's, no
mouse, no *display* for that matter (though I might give the little
*******s a single hex-digit LED). You can learn an awful lot about
programming by working with a truly constrained system.

Aboslutely. Maybe they ought to bring back the KIM-1, at least.
FOr that matter, cut back opon the use of Java for instruction,
certainly at the loser levels. Yes, it's got a lot of neato Bells &
Whistle, and you can easily play the Object Game, (and its easy for
the instructor to correct) but it's like watching a duckling swim -
the student sees it sliding smoothly throught the water, without
seeing all the frantic paddling going on underneath.

And we had to eat dirt. And there wasn't any air.
(Henry Spencer was around, though)

Well, most kids eat dirt at some point, but I think all
the living ones had air throughout most of their lives.

'Twas a joke, son. The inevitable progression of the "Kids these days
don't know how good they have it" dialogue.

--
Pete Stickney
A strong conviction that something must be done is the parent of many
bad measures. -- Daniel Webster

In article ,
Brett Buck writes:
Peter Stickney wrote:

In article ,
Grant Goodes writes:


I've made a very interesting but promotionally-challenged career out of
being the poor suckah that understands both the HW and SW sides of the
design, and fights to make the two form a functional if uncomfortable marriage.
There's a reason why _good_ people for this kind of stuff are scarce: It
doesn't get you recognized as a valuable asset to the team, since you
challenge sacred cows on both sides of the HW/SW divide.


It also seems to be a difficult thing to teach, especially in this day
& age. Perhaps unfortunately, the rapid growth in performance, and
the decreases in cost, in the "consumer" sides of computing have
allowed Egregious Software Bloat to become the norm. When even a
driver won't fit on a 3.5" floppy...


For space-project programmers, you really need people who are
aerospace engineers with computer programming skills, as opposed to
computer programmers that go into aerospace. Not necessarily by
training, but certainly by orientation. The skills set and mind set
required to do large consumer code projects are significantly different
than embedded systems, even if the language is the same. Not a value
judgement, but an observation from experience on all sides of this fence
(H/W engineering- flight operations - flight S/W programming -
guidance & navigation design engineering, with technical supervision
during each). Some programmers out of school "get it", and a whole lot
of others don't. The percentage who don't has gone up astronomically in
the last 10 years as programming has grown as a profession. What they
teach in schools *does not* seem to translate well into capable and
properly oriented aerospace programmers. I have to assume they know how
to do consumer software, but I couldn't say.

On the Consumer Code vs. Useful Stuff debate, I heartily agree.
I agree about the education bit, too, but...

If I may, Brett, what makes the code of a Spacecraft so different than
that of any other real-time process control and data acq system that's
going to be unattended for extended periods?

Looking at the system from its most basic level, the requirements for
reliability, fault tolerance, resource and task management, etc. don't
seen all that different between a space probe and, say, a remote
sensing station intended to be dropped on the Antartic ice, or a deep
ocean probe. They have to be equivalently accurate and reliable,
since they're going into inaccessable systems that will have to
operate unattended for their lifetimes. Yes, the environments are
different, but equivalently difficult, and some of the "Applications"
(Guidance & control, particular sensors) are different, but the core
system (kernal, if you will) seems to have requirements independant of
its end use.

I've not worked directly on any flight space systems, but I have done
the deep ocean and Antactic stuff, and a Metric Bucketload of other
real time control and Data Acq systems. I'm curious to see if I'm
missing something, here.

--
Pete Stickney
A strong conviction that something must be done is the parent of many
bad measures. -- Daniel Webster

On or about Fri, 9 Jan 2004 00:23:26 -0500, Kevin Willoughby
made the sensational claim that:
He explained that they wrote some software, then
took a trip to Cape Kennedy to watch the launch of HEAO-B/Einstein and
then returned home to write the real software for that spacecraft.

Cape Kennedy? Where the heck is that? :-P
--
This is a siggy | To E-mail, do note | This space is for rent
It's properly formatted | who you mean to reply-to | Inquire within if you
No person, none, care | and it will reach me | Would like your ad here