In the link I shared, there's a URL to this presentation slide set.
https://www.safetyresearch.net/Library/BarrSlides_FINAL_SCRUBBED.pdf
I read through the Barr report.
Seems basic stuff like watchdogs were not implemented, excessively complex functions and up to 16 million potential failure modes if I understood it correctly totally out of control and untestable.
Of course I’ve never written embedded code that’s more than 1-2 thousand lines (C, C++) and keeping track of all that was difficult enough so I would imagine many thousands of lines of code and multiple coders must be a tough project to manage.
Nevertheless, some of the stuff Toyota did is unforgivable. I have WD’s on all my stuff since it’s real-time.
When the 737 report comes out, it will make interesting reading. I some how feel it will lean more to bad management decisions than plain bad coding practice. But, we won’t know until then.
Seems basic stuff like watchdogs were not implemented, excessively complex functions and up to 16 million potential failure modes if I understood it correctly totally out of control and untestable.
Of course I’ve never written embedded code that’s more than 1-2 thousand lines (C, C++) and keeping track of all that was difficult enough so I would imagine many thousands of lines of code and multiple coders must be a tough project to manage.
Nevertheless, some of the stuff Toyota did is unforgivable. I have WD’s on all my stuff since it’s real-time.
When the 737 report comes out, it will make interesting reading. I some how feel it will lean more to bad management decisions than plain bad coding practice. But, we won’t know until then.
There was the Therac-25 which was apparently a smaller project code-wise, but from what I read somewhere it was all written by one person, who didn't have even half decent programming practices. Then again, I learned 6502 assembly circa 1977, and C in 1987, and the only helpful programming paradigm I knew of for many years was structured programming. That's now so old hat and assumed to be part of programming that it's not even mentioned anymore.
I've been catching up in the last few years, there are many methods and "paradigms" to improve programming practices that have been developed in recent decades. Making the code clearer and easier for humans to read just happens to make bugs easier to see and fix, making the code more reliable.
It's arguable that bad management led to bad coding practices, which is inexcusable in companies the size of Boeing and Toyota. For the Therac-25, if it's in any way "excusable" that a smaller company had bad management practices that led to bad coding practices, then the company shouldn't have done that product.
I have this idea that totally goes against commercial "trade secrets" and such, but I wonder if safety-critical code should be made open source (or under an "open readable" license - you can study it and publicly critique it all you want, but need permission to use the code in your own product).
Well the good part is that it is a rather tightly controlled temperature environment for the electronics.
When the temperature environment strays +/- 5 degrees, it doesn't matter if the pacemaker works..
jn
I remember that event sequence chart. What a mess.
They went lead free by edict at work when I took a week vacation...I really really took issue with that. It took a while, but I got them to reverse that.
The RHOS exceptions were the "out" I provided upper management.
Even now, many of the COTS units will have one or two components in them that grow whiskers. we have about 5 thousand units, so on occasion have to troubleshoot. So ridiculous to have to deal with incorrect global decisions.
jn
I often wondered if the steering wheel was attached on my old 77 ford 1 ton!
It's always the fault of the nut holding the steering wheel..
jn
Talking about steering wheels, when I was involved with auto ('96 - 2001) there were a few projects in progress at the big tier 1 suppliers looking into 'steer by wire'. The push to get autos weight down is huge and theengineers figured if they could throw out the traditional steering systems with their linkages and use small motors plus gear wheel at each front wheel, they'd save quite a bit of weight. I left to go to another business within the company in 2001, but AFAIK it was never taken up by the auto manufacturers.
Steering assist nowadays is almost always done with a small electric motor that helps you when you turn the wheel - gain, big weight/hazardous materials savings over traditional servo systems. My wife once had a Peugeot 101 - tiny car - without steering assist. She developed strong arms
Steering assist nowadays is almost always done with a small electric motor that helps you when you turn the wheel - gain, big weight/hazardous materials savings over traditional servo systems. My wife once had a Peugeot 101 - tiny car - without steering assist. She developed strong arms
Interesting. I did a bit of assembler coding on the Z80 and 8085 back in the day and then some on one of the ST controllers. I only got back into coding about 12 years ago and it was on the Philips 8080 derivatives and the Kiel 'C' compiler - but I quickly ditched all that and went down the ARM route and the mbed platform when Philips brought out the ARM emebedded processors (industry first - raised a lot of eyebrows at the time but ended up fundamentally changing the whole industry).
Once you've started using 32 bit emebedded processors, its very difficult to go back to 8 bit - well let me put it this way, you probably a masochist! I've not tried the Microchip 32 bit devices - but they'll also be pretty good.
I only will believe that a piece of software is error free if all three of the following conditions are simultaneously met:
1 - No more than 2 lines of code;
2 - It ran for 10 years with no problems;
3 - I wrote it.
If I ran a software company, I would never hire anyone who even believed that error-free software exists. Such persons are dangerous.
Jan
1 - No more than 2 lines of code;
2 - It ran for 10 years with no problems;
3 - I wrote it.
If I ran a software company, I would never hire anyone who even believed that error-free software exists. Such persons are dangerous.
Jan
I worked with a software engineer once (I did the hardware side) who proudly told me when we met for the first time 'I don't make mistakes'. The project took a year and it was his first big challenge.
He was quite humble by the end of it. If there's one thing I learned, it was to go back and check my work 2 or 3 times. I fell out to the habit in DIY and every now and then get 'humbled' by people pointing out my mistakes. Right first time methodology takes a lot of personal discipline and effort - but it can never totally eliminate what I would call 'honest' mistakes.
He was quite humble by the end of it. If there's one thing I learned, it was to go back and check my work 2 or 3 times. I fell out to the habit in DIY and every now and then get 'humbled' by people pointing out my mistakes. Right first time methodology takes a lot of personal discipline and effort - but it can never totally eliminate what I would call 'honest' mistakes.
TeX is getting close. It is used enough to exercise the bugs. Knuth pays a few hundred for bugs. It has been stable since 2014; before that 2008. It will not be changed after Knuth's death, "at which point all remaining bugs will become features".
TeX - Wikipedia
Even if software was perfect, the processors ALWAYS have bugs, even back in the 8 bit days.
Modern 64 bit mult-cores are only getting worse as Intel has found out with Rowhammer
Reading this article about the latest report, it looks like Boeing will be required to do all the things it should have been doing all along:
NASA Update on Orbital Flight Test Independent Review Team – Commercial Crew Program
Indeed. Hugely complex machines at every level - errors are bound to creep in.
Those are basic measures even for non safety critical software of any importance at all.
What did Boeing think they were doing?
They lost site of why they exist as a company: to build great plane’s profitably and instead focused on quarterly results and executive remuneration.
Happens to a lot of listed firms. In the process they lose their way.
You can debate whether the listed omissions etc are really software errors. For me they are more design flaws.
For the MCAS to look only at one of the AOA sensors and getting lost when that part malfunctions is a design flaw, not a software error. The software worked as designed, they just had forgotten to 'tell' the software what to do when the AOA sensor would indicate impossible angles.
Jan
For the MCAS to look only at one of the AOA sensors and getting lost when that part malfunctions is a design flaw, not a software error. The software worked as designed, they just had forgotten to 'tell' the software what to do when the AOA sensor would indicate impossible angles.
Jan
- Status
- Not open for further replies.