State Machine
Janitor
Joined: Apr 17, 2006 Posts: 2809 Location: New York
Audio files: 24
|
Posted: Tue Dec 11, 2012 8:20 am Post subject:
Some good programming and quality control Advice Subject description: A Shuttle Failure Averted |
|
|
********************************************
I thought this was good information. Although our software we develop for our DIY electronic music instruments may contain bugs that lurk within, if a bug shows does show up may not cause death, it would certainly mean the difference between a great live performance OR a musical disaster !
********************************************
Taken from: The Embedded Muse
Issue Number 232, December 10, 2012
Copyright 2012 The Ganssle Group
A Shuttle Failure Averted
The second Space Shuttle launch in 1981 was delayed by a month when a fuel spill loosened a number of its tiles. The crew booked simulator time in Houston to practice a number of scenarios, including a "Transatlantic Abort”, where the vehicle can neither make orbit nor can return to the launch site. Suddenly, all four main Shuttle computers (in the simulator) crashed. Part of the abort scenario requires fuel dumps to lighten the spacecraft. It was during the second of these dumps that the crash occurred.
After a couple of days of analysis, programmers discovered that the fuel management module, which had done one dump and successfully exited, when recalled for the second fuel dump, restarted thinking that this was it's first incarnation. Counters in the code had not been properly reinitialized, though, causing what was essentially a computed GOTO to branch out of the code, into a random section of memory.
A simple fix took care of the problem. More interesting, though, was the realization that this same sort of bug had appeared in different modules before. The programmers were committed to producing only the best code, so decided to see if they could come up with a systematic way to eliminate these generic sorts of bugs in the future.
They developed a list of seven questions that had a high probability of isolating similar problems. A different group of programmers then applied these questions to the bad fuel dumping module (to see if they would indeed pick up the known problem), as well as other modules.
The questions detected every one of the bugs. 17 additional, previously unknown, problems surfaced!
This is software engineering at its best. Instead of quickly fixing the bug and moving on - as most of us do - the development team transformed the defect into an opportunity to improve the code |
|
JovianPyx
Joined: Nov 20, 2007 Posts: 1988 Location: West Red Spot, Jupiter
Audio files: 224
|
Posted: Tue Dec 11, 2012 9:22 am Post subject:
|
|
|
Wow, very interesting and pertinent here because as you said, there's nothing worse than being on stage with an audience watching as your DIY synthesizer or effect farts and dies.
From the standpoint of a musical device, I believe in "over" testing. As I develop code and before it is completed, I run tests, proof of concept if you will, because often what I do is an incremental building process and often if not always, one piece of code depends on others working correctly. I write code (usually in C) to simulate the process idea and often work out problems at that stage.
Unit testing is important and I always try to over stress the device code, such as blasting high bandwidth MIDI data at it as well as unexpected and malformed data, just to see whether the code will tolerate it and recover when good data is presented afterward.
I will also leave the unit powered up for days at a time quiescently and then send more test data (MIDI) to see that it still functions correctly after sitting idle for many hours.
Final testing includes an attempt to create a piece of difficult music which I eventually use as a demo mainly to show off the instrument's features, but that demo has been played over and over during the recording process to ensure it sounds exactly as I intended.
Finally, I will try to find MIDI files of complex classical music to fire at it in case subconsciously I have written the demo to conform to a "be nice to it" paradigm. Given that the composer was not me, that can't happen. I am not satisfied until I've remediated every glitch that my ears can hear. _________________ FPGA, dsPIC and Fatman Synth Stuff
Time flies like a banana. Fruit flies when you're having fun. BTW, Do these genes make my ass look fat? corruptio optimi pessima
|
|