General > General Technical Chat

Another deadly 737 Max control bug just found!

<< < (17/37) > >>

Rick Law:

--- Quote from: splin on July 17, 2019, 01:23:23 am ---...
...
 Software that takes longer to develop than the life cycle of the product it's used on is pointless.

--- End quote ---

I think software problem is more because of it being "lower entry barrier."  Anyone with enough money to buy a cheap laptop can start developing software.  Compare the cost of starting a new software development company to say cost of starting a company to develop a new video chip to compete with NVIDIA.  The ratio of the two cost-of-entry would (with exaggeration) overflow a typical calculator.

This low entry cost of software development leads to the average quality of the developer, quality of the development shop, experience of the development shop all correspondingly lowered.  You could, in theory, have people writing software for a washing machine who has never seen a working washing machine, and they are writing their washing machine software in a shed next to a river bank next to the bunch of people washing their cloths on the river shore.  You could do software in that environment, but you are not going to develop any new IC's of complexity sitting in shed with bathrooms in the out-house.

Yeah, I exaggerated.  I exaggerate to point out how the lower entry barrier can bring in much lower caliber teams.


--- Quote from: floobydust on July 15, 2019, 03:36:04 am ---...
I wonder if the money and lives lost will ever be a motivator to do it right, or will it be just investor's cash being burned for a little "hiccup".

Instead of parking lots full, maybe Boeing could turn the planes into condos? Just park under the wings.

--- End quote ---

They will remember it for a while, sack some of the ones involved (who merely followed order too do everything needed to reduce cost), and bring in new blood.  Hiring these new blood will be announced as investment to make sure such problem will be fixed and make sure such fiasco will never happen again.  As their stock improves (even if the stock price increase is due to improvement in the general economy or due to inflation), their memory fade as the stock price rises...

The incoming new blood will of course hire more new guys.  Most important of the new hires will be the ones for the new marketing team - the team that will do magic to wash off the stain of "sins of prior management team" in the public's (and the customer's) eyes.  But, the new marketing drive needs funding.  So, budget cut for the development groups to fund the new marketing drives.  They did a bad job that caused the problem, so they deserve to have their budget cut to the bone and then some.  They will be told to find ways to do software development "smarter".  That is to say, do it faster, better, and with even less money.  If the development team(s) can't do that, we fire the whole lot and outsource the whole darn thing.

GeorgeOfTheJungle:

--- Quote from: Rick Law on July 17, 2019, 02:40:10 am ---You could do software in that environment, but you are not going to develop any new IC's of complexity sitting in shed with bathrooms in the out-house.

--- End quote ---

Look: youtube.com/watch?v=QqxThgLTLyk&t=7m54s :-)

Part one: youtube.com/watch?v=jhwwrSaHdh8 and part two: youtube.com/watch?v=re5xAqgKqc0

David Hess:

--- Quote from: splin on July 17, 2019, 01:23:23 am ---
--- Quote from: David Hess on July 10, 2019, 03:49:44 am ---And why machines for which the state cannot be documented due to things like heap allocation should not be used in safety critical applications.  This also makes processor features which contain unknown state like caches, speculative execution, and multi-threading less desirable.
--- End quote ---

Except that pretty much any non-trivial system will use heap allocation - but it will be called something else, typically a buffer pool or the like. Try, for example, implementing a comms protocol without one. These pools will be safer than a global heap because (at least):

...
--- End quote ---

How complex does a system involving physical control loops need to be?  Separate it and stick it on redundant hardware.

Static allocations are wasteful but so what?  Memory is cheap.


--- Quote ---For safety critical applications you obviously must be able to guarantee the behaviour of the critical parts of the system and isolate them from less trusted subsystems. The reality is that tradeoffs between cost, development time/effort (re-certifying a 737 MAX), functionality and safety are always being made - there rarely absolutes - if ever. No point in a seven-nines reliability requirement if it costs ten trillion dollars. Or a car ECU which costs $1500 and can't do MP3. An aeroplane with enough redundancy to be guaranteed never to fail is probably too heavy to fly. Software that takes longer to develop than the life cycle of the product it's used on is pointless.
--- End quote ---

I suspect the larger problem is that the programming techniques are no longer taught and the tools are no longer available.

In this case none of that mattered because the system operated exactly as designed.  It was just designed ineptly.

coppercone2:
there is a obsession with memory space in conventional software design that should not be carried over to embedded systems. Even with code clarity.

windsmurf:

Speaking of memory space, memory overflow is forcing Airbus planes to power cycle the entire avionics suite every 149 hours

https://www.theregister.co.uk/2019/07/25/a350_power_cycle_software_bug_149_hours/

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod