You may redistribute this newsletter for non-commercial purposes. For commercial use contact email@example.com. To subscribe or unsubscribe go here or drop Jack an email.
Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.
|Quotes and Thoughts
One-third of all software faults take more than 5000 execution-years to fail. Thus, testing is an inadequate way to insure correctness. Adams, N.E "Optimizing preventive service of software products", IBM Journal of Research and Development, 28(1), p. 2-14
|Tools and Tips
|Here are the tool reviews submitted in the past.
Earlier this month a probable transient fried the computer board in my telescope's mount while I was in the field trying to image a galaxy cluster. After dismantling the thing it's clear the PCB assumes power will be pristine, though the burnt components testify to a less-wonderful reality. When the replacement board arrives I'll add a zener diode and MOV to make the PCB more robust. So this article in Electronic Design about overvoltage protection is topical and of importance to those of us who design circuits with oh-so-delicate components. Recommended.
|Freebies and Discounts
The giveaway is on holiday for the summer.
|Schiaparelli and Fuzz Testing
Jakob Engblom has a useful take on the ESA Schiaparelli failure. This was (yet another) unsuccessful Mars mission that crashed on landing in 2016. (Mars is tough; it seems to eat spacecraft, though in recent years we've seen some incredible successes).
In short, the software experienced an unexpected out-of-range condition it couldn't handle. Jakob makes a very interesting point that the error might have been spotted had the software team employed fuzz testing (alluded to in Muse 450). His article has this image:
I think this makes a quite compelling case for fuzz testing. Normal tests only check things we anticipate. After a half-century in this field I'm convinced none of us are as good as we think, and we rarely realize just how mischievous the universe can be.
Now, fuzz testing may not find all, or even some, errors, but it does subject a device to extremely unexpected inputs.
(Back in the 1970s we had our own form of fuzz testing; we called it Shirley Testing. Shirley was a wonderful young woman with a limited education who had a preternatural knack for breaking our code. In our youthful hubris we built The Most Robust Firmware Ever... but Shirley was sure to find a combination of inputs that embarrassed us and forced the team to write code that questioned every input.)
To be clear, while test is incredibly important, it is just one tool in ensuring our code is correct. Too many teams rely mostly on test; Schiaparelli and so many other failures demonstrates the limits of that strategy. I think a philosophy of using it to find bugs is a mistake; test should be a process that demonstrates that the system does indeed work, the mistakes nearly all caught earlier in specification, design and the like. But test remains extremely important and is shortchanged much too often.
|RANSAC Curve Fitting
I recently came across a new-to-me way to fit data to a curve that anticipates and deals with bad data.
We've long used methods like least-squares (LS) approximations to fit experimental data to a curve. Least squares often does a decent job, but is somewhat flawed in that it all of the data is given equal weight. "Outliers", aka "bad data", are those points that just don't fit the curve. Alas, least squares will happily include these in an approximation. In the past I've used LS to fit curves and then went back and excluded data whose error was more than some standard deviation from the mean. Unfortunately, the outliers necessarily corrupt the fit so there's no guarantee that such exclusions will get rid of the bad stuff. Sometimes the cruft will seriously skew the data you want.
Wikipedia gives a nice high level description:
The Wikipedia article gives example code.
While LS will always give an answer, RANSAC does not necessarily converge. And, in my experiments, it can take a lot of iterations to come up with an acceptable answer. But CPU cycles are often cheap so thousands of iterations can be a viable option.
If your data is plagued by outliers that are hard to identify and exclude, check out the RANSAC algorithm.
Last week's images from the James Webb observatory are stunning. Wednesday Marybeth and I attended a lecture about Webb's results and the presenter, a NASA astronomer, was excited beyond words. Though Webb has suffered a difficult birthing process it appears we now have a new science resource that will hopefully shed new light on the cosmos. In July of 2011 as the mission was again facing the knife I wrote the following article that appeared on embedded.com:
One scene in Fiddler on the Roof has the following amusing dialog:
Perchik: There's a question... A certain question I want to discuss with you.
I try hard to be apolitical in these columns, but like Perchik I sometimes feel, in these troubled times, that the political intrudes on many areas. Today our elected representatives pretend to scrutinize every dollar, sometimes making what I believe to be dumb decisions.
According to http://appropriations.house.gov/news/DocumentSingle.aspx?DocumentID=250023 and
Unlike so many other government programs, a year ago the program passed the technical part of a huge design review, signaling that the design is sound.
The Subcommittee's recommendations are just that, but they carry significant weight, and the thinking is that the JWST will likely be scrubbed.
I think that, despite all of their problems, NASA has been one of the shining beacons of the government. Sure, there's plenty of waste. The ISS is pretty much devoid of any mission, and the Shuttle, now in its grand finale, was compromised by too many interests.
It's easy to pick a government agency apart and expose all of their flaws. But NASA has had some successes that are so brilliant they outshine the problems. There's the Cassini–Huygens mission which, among many other things, found that Titan has liquid hydrocarbon lakes, making it and the Earth the only bodies found with large lakes.
And consider New Horizons: it's expected to reach Pluto on July 14, 2015 (it was sweet of the mission planners to place it there on my birthday - thanks, guys!). Visiting one of the development centers I noted a bumper sticker on an office door: "My other vehicle is on its way to Pluto!"
The Hubble Space Telescope is another example. Not only has Hubble expanded our vision of the universe, it has uncovered major problems in physics (dark matter and energy) that could possibly require a major revamping of our understanding of how the cosmos works. What an exciting time to be a physicist!
I've seen Hubble photos in art galleries. How often does the fruit of a scientific mission inspire artists and the average Joe?
Like the JWST, Hubble was born over-budget and was laughably launched with distorted vision. But those problems are long-forgotten; for two decades it has been returning images of unprecedented quality. It's getting old and will never be serviced again. Long before the JWST's launch it will likely be cold and dead, tumbling till it returns and burns up.
We need this sort of imagery. JWST is a phenomenal mission that will keep us peering deep into the heart of the cosmos.
The Webb Telescope is a risky mission. It'll be 1.5 millions miles out at L2. Technically complex, in an unserviceable orbit, the craft could fail. Spaceflight has always had its risks, which can be eliminated in only one way: never launch, never try something new and daring.
We face historic and possibly Republic-busting budget issues. I've been crusading against the staggering deficits we've been running for three decades. I support fairly draconian action, and not the kind any of the players in DC are advocating.
But some programs must remain, and the JWST is one of those.
|Failure of the Week
From Fernando Medrano:
From Ken Lyons:
Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.
Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
|Joke For The Week
These jokes are archived here.
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.