I believe that's right. I confess I'm not so interested in formal proofs in the mathematical sense. (Would the proof be bug-free itself?)
What I *am* interested in follows on from this perceived distinction between "trivial" and "complex". I've said elsewhere (many times) that a complex system consists of many simple parts. My aim, always, is to reduce complexity down to a collection of trivial parts. By "demonstrably bug-free", I mean that any (competent) designer should be able to look at the code and deduce, fairly rapidly, that it's all so simple that it *must* work. I use a variety of techniques to achieve this, but it basically comes down to modularisation and hierarchical design.
You say "no-one is perfect". Again I agree. That's largely why I use methods that limit the amount of mistakes I can make - and then I try to ensure they're big ones which are easy to spot ;).
Why? Because flexibilty of software is its curse, coders rewrite software if it's not optimized to a specific task and that is where all of tomorrows problems are constantly being created.
For circuit designers, for instance, you can't do that unless you have a fab shop sitting next to your desk, you are forced to use whatever is available, with no changes, even if the design will be twice as big and ten times as slow as a custom chip solution would be.
This gross inefficiently wouldn't be tolerated in the software engineering world, because a custom solution is just a few keystrokes away, which means change, which means errors, it's the nature of the beast.
2x4's or 2x6's are commonly available, cheap, and professionally cut and dried at a saw mill, but a software guy would cut his own 2x4.5's, if that is exactly what he needed, even if they were hand sawed in his basement.
The proof of all this can be seen in the recent use of programmable logic devices (PLD's) in safety critical hardware, PLDs can be classified as "easy to customized hardware", and this led to the birth of DO254, the hardware version of DO178. The same logic that was previously implemented with discrete parts needed to meet very minimal formal development procedures to be certified in a flight critical system (for better or worse, but that is the way it was), now, the exact same logic, contained in one big programmable part, must meet all the strict developement rules as software, only because the logic is now implemented in a "easy to change" format.
This is the problem. People CAN'T understand the entire problem or all possible interactions. An individual module may be bug free at the level of the original requirements and the uses it was expected to undergo, but the interaction with other modules, reliance on other modules, changing requirements, and unexpected uses can changes this.
- People come and go, and the experts on a module vanish before they can document things (I'm being generous here and assuming they would have documented if they had a chance :-)
- Engineers are stretched thin and end up having more modules to understand than the time alloted to understand them.
- Products are rushed, and there is no time to validate every possible interaction before the budget runs out. Engineers rarely have control over product ship dates if they don't own their own company. These aren't artificial deadlines - these may be deadlines necessary to keep the company alive.
- Requirements change. New hardware comes out and the old software is expected to be ported to it, not redesigned for it.
- Vendor supplied software is often broken and support can be a pain.
- Hardware has errors, not all of which are documented.
Of course, software *could* be designed to take into account all of the hurdles that always come up. But it rarely happens. Mostly because a lot of people aren't aware of the need, and because it takes more time. I don't have the time to rewrite all of the code, so I have to deal with the existing mess and hope I find all the places that need porting or that may interact with my changes.
On the other hand, I worked one integrating software from a team of engineers who placed emphasis on make sure every module was highly portable and customizable. The drawback though was that they spent more time trying to make things reusable that the project was never finished. They did create a lot of modules though, some of which actually were portable. So there needs to be a compromise between the two ways of looking at things.
Hmm, I see lots of complexity in hardware and mechanical design that isn't always well managed. They hit the same sorts of problems as software. I've seen both of these have to get some redesign after experience in the field. Ie, the center of gravity isn't right for trying to roll the device into a hospital elevator, springs don't work as expected, higher voltages are required for later features, cost reductions involve slightly different parts being used, too much RF leakage, too much EM noise, too much fan noise, etc.
If "well managed" means that the problems eventually get solved, then software is also well managed. But if well managed means bug-free when shipped, then no, mechanical and hardware is not always well managed.
I suspect that these fields are not golden either. Just that spending more money to test and eliminate bugs can be justifed. But bugs will remain none the less.
I trust that you are not using the fact that the brakes work is an idication that the braking system software is free of bugs. It's my rant that poor coders ask if something works rather than asking if something can be made to fail.
The exception was handled as intended, ie. "correctly", for the Ariane 4 context.
For Ariane 4, the designers considered this overflow to indicate processor failure. Therefore, they designed the exception handler to emit diagnostics and shut down the processor, passing control to the redundant processor. However, on Ariane 501, of course both processors hit the overflow, since they ran the same software and got the same inputs. Both shut down, and no-one was in control.
In this sense, on this point, in my opinion, the Ariane 4 SW was bug-free for the Ariane 4. Granted that the exception handling did not consider possible SW errors, only HW errors, leaving SW errors as fatal single-point failures.
The proper objective is to analyze the reason you made a mistake, and try to arrange things, or attitudes, to eliminate, or at least reduce, that possibility.
In a c.l.c. thread recently I responded to a newbie wanting to elide blanks in a string with the following faulty code:
source = dest = argv[1]; do { while (' ' == *source) source++; *dest++ = *source++; } while (*source); *dest = *source;
while a proper solution was:
source = dest = argv[1]; while (*source) { if (' ' != *source) *dest++ = *source; source++; } *dest = '\0';
and I concluded that the problem was using a loop with side effects inside a controlling outer loop. This is a design fault, and language independent.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@maineline.net)
Available for consulting/temporary embedded and systems.
USE maineline address!
Yes, but the ability to change means the product or board gets a longer lifetime. This can be essential to the very existence of a product in some instances. Ie, not all features have to be implemented at first ship, and the project can plan for future performance upgrades. Of course, if everyone had the time to get the product perfect before the first shipment it wouldn't be necessary.
In which case you may be interested in the white papers at about Mesh Computer Chips. This is quite new stuff so not a lot there at the moment but worth bookmarking and looking into.
While it does deal with the UI aspects of a system it does go a bit deeper than that and shows how architectural decisions can affect useability of a system. It is worth the read anyway and you are going to have to appreciate the topics in this book no matter how deeply embedded and distant from a human user your system may be. After all, not all users of a system are human.
When asking questions here it is worthwhile mentioning what research you have done with Google just so that we don't have to roll out the links to material you may have already discovered on your own (some cross-over is useful but not reams of it).
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
That they do. However, it should be remembered that trivial systems, conmnected together in the right way, can collectively form a very complex control system. some of the idea behind Mesh Computing.
The one thing you have to prove in court is that you used "Best Possible Practice". having a process that works, is audited and proven to be applied is definitely a help towards such a defense. You are right that we cannot produce perfect systems but we can at least work towards proving we did our level best to do so.
There was something about that then and I think you would find that under "The Halting Problem". That was, ISTR related to anything but "Trivial Programmes".
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
No people design first and test as much as possible to prove they have as many conditions covered as possible, thankfully ensuring that the bug count is vastly reduced compared with other fields.
No.
Too true.
I first check any changes work and system works as expected, then check to see if I can make it fail in ways it failed before as well test conditions old and new or even random new ones to add to the list.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
If you begin to approach every project as though you will end up in court and aim to gather enough evidence to ensure you win your case you will be OK most of the time. By evidence I do mean that information which is collected in accorance with the "rules of evidence". Logs, registers, documentation, contracts etc.
But the real world always gets in the way and it is up to the proper engineers to deal with this aspect and the best ones always seem to manage to.
I am one who agrees that the most important structural issues for a product should be fully resolved before the technical specification gets written (ie, during requirements specification). Requirements specifications need to be tested more thoroughly than the final product and demands more up-front time to get right than any other stage of development. This may sometimes be frustrating of the client that wants to see results 5 minutes after they release the spec but your best diplomatic efforts should quell this unnecessary need in them.
As one who deals with the design and development of products that would lead to great problems should they fail during their 25+ years expected life, I found I spend quite a long time correcting the requirements specifications before I get anywhere near starting a tech spec. It is always effort well spent though.
It is worth benchmarking the performance of your development process to see how it aids or hinders the corporate goals for legislative and standards compliance, timeliness and profitability. Know what time you spend where and what the overall company benefit is (it becomes easier to sell to management when you want to introduce a new procedure aimed at improving performance and accuracy).
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Dealing with just this issue. You are right that people have a problem understanding all the possible interactions of a complex system as a whole. However, the thing about decomposing the system until the level of problems approaches close enough to trivial that we do fully understand the interactions of that section is a technique worth developing for any engineer. By fully understanding the simple parts we get to understand the more complex bits without the undue burden of the underlying simple parts.
Much of this decomposition effort will yield a vision of a natural structure for the overall system that allows development of the simple parts and testing of same in the appropriate places in ths structure. You should also be able to identify good prospects for reuse ase well.
--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
One other thing: the word "interaction" keeps getting mentioned. There should be none - other than those intended, of course. Possibly *the* most important part of good design is defining the interfaces between the "trivial" bits.
While in principle dividing a complex task into multiple simple tasks should be the way to solve complex problems, in practice you are faced with the problem of last minutes changes demanded by the customer that would require redesigning the high level architecture.
If you are in the ideal position of saying that any change will require some drastic changes in the system architecture and will delay the project with x month and will cost you xxx euros, then this path should be used to create a product that is maintainable even in the future.
Unfortunately, these options are not always available and some quick and dirty patches must be done to already fixed architecture.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.