design rigor: electronics vs. software

On Saturday, January 11, 2020 at 12:46:23 AM UTC-5, snipped-for-privacy@gmail.com wrote :

I think that is a load. Hardware often fouls up. The two space shuttle di sasters were both hardware problems and both were preventable, but there wa s a clear lack of rigor in the design and execution. The Apollo 13 acciden t was hardware. The list goes on and on.

Then your very example of the Boeing plane is wrong because no one has said the cause of the accident was improperly coded software.

Yes, it was an improper spec, with dangerous reliance on poor hardware.

The easier it is to change things, the less careful people are about doing them. Software, which includes FPGA code, seldom works the first time. Almost never. The average hunk of fresh code has a mistake roughly every 10 lines. Or was that three?

FPGAs are usually better than procedural code, but are still mostly done as hack-and-fix cycles, with software test benches. When we did OTP (fuse based) FPGAs without test benching, we often got them right first try. If compiles took longer, people would be more careful.

PCBs usually work the first time, because they are checked and reviewed, and that is because mistakes are slow and expensive to fix, and very visible to everyone. Bridges and buildings are almost always right the first time. They are even more expensive and slow and visible.

Besides, electronics and structures have established theory, but software doesn't. Various people just sort of do it.

My Spice sims are often wrong initially, precisely because there are basically no consequences to running the first try without much checking. That is of course dangerous; we don't want to base a hardware design on a sim that runs and makes pretty graphs but is fundamentally wrong.

If code kills people, it was improperly coded. Did Boeing's programmers know nothing about how airplanes work? Just grunted out lines of code?

Winfield Hill wrote in news: snipped-for-privacy@drn.newsguy.com:

Thanks Win. That guy is nuts. Boeing most certainly did announce just a few months ago, that it was a software fault.

Dork C does this often.

That's the opposite of my position. I'm sure the coders made the software do exactly what they were told to make it do. It was system engineers and their managers, who made the decisions and wrote the software specs. They should not be allowed to simply blame "the software".

GiGo (Garbage In Garbage Out) i.e. a garbage specs given to programmers will produce garbage code, which is tested against the (garbage) specs :-)

A competent programmer might ask e.g. about redundancy issues but are easily turned down by upper management.

Winfield Hill wrote in news:qvcpg901bm2 @drn.newsguy.com:

Well, it WAS the finished product that failed, but the true failure was their ability to ensure proper, robust, failsafe coding.

Altitude and heading maintaining 'auto-pilot' is OK, but full on willy nilly 'take over' of a major manueverabilty aspect of the controls is ludicrous.

And the hardware is faulted too. That jackscrew needed a split threaded sleeve on it so it could be released if a catastrophic failure occured. Yet one more failure point.

The thing is that assuming control over the elevator of a huge multi-ton mass speeding through the air not very relatively far from a catastrophic ground impact is a bad idea to say the least.

If people can die from bad specs, the programmers should refuse to write the code.

Some of the things that the MAX code did were insane.

"We were just doing our job." Where have we heard that before?

snipped-for-privacy@downunder.com wrote in news: snipped-for-privacy@4ax.com:

You're an idiot. Redundancy is a primary aspect of any mission critical flight control management.

Can't have a redundant jack screw.

Don't need a redundant atitude sensor. The atitude sensor needs a mechanical attachment that would allow a pilot to jiggle it to ensure that it is freely moving and reacting properly to the plane's position changes. OR use that mechanical conection to manually adjust a flawed sensor so that the system performing the physical control at the elevator would get 'good data' from the sensor and the runaway condition can be recovered from.

They were not given 'garbage specs', so your shithouse programmer attitude does not even apply.

To me your operative word is, proper. I'm sure the code was robust in doing what it was spec'd to do, and likely included failsafe coding as well. It was improper specs that created a non-failsafe system.

No doubt the coding was broken up into pieces, each of which acted in specied manners for its variable inputs, and which may well have obscured the overall task.

In fact, the output code that implemented the minor "augmentation" function may not have been revisited for changes, after the systems-level decision was made to expand the use of the augmentation system, to add anti-stall.

snipped-for-privacy@highlandsniptechnology.com wrote in news: snipped-for-privacy@4ax.com:

Heard it a lot from captured Nazi war criminals.

Lemmie see... Ollie North... Trump's retarded cabinet...

There is a very well known rule about software (assuming you include FPGA H DL as software) that says it is much, much easier to find bugs early rather than late. I write code that is tested in simulation, thoroughly, and sel dom has bugs when run in an FPGA. Yes, even "seldom" does not preclude bug s, but they are the exception, not the rule as you indicate.

I suggest you have your HDL designers spend more time working on their code and less time debugging it in the chip or worse system, the hardest place to find bugs.

Usually the large number of bugs found in software compared to hardware is due to the fact the software has much, much more to do than the hardware. I would expect that to be pretty obvious to even a casual observer.

When a description of development refers to people working "carefully" it s ounds like a very undisciplined effort. I've worked in Mil spec environmen ts where the process was formalized. Then the level and processes of "care " are standardized and consistent.

PCBs typically work the first time because they are simple, easy to review and simple to specify and analyze. PCBs are the poster child of easy to ge t right the first time by applying requirements and evaluating to those req uirements.

In your organization.

And yet you don't bother to apply rigorous design techniques to any part of your design process preferring to work by massive amounts of inspection an d testing. Ok, but that won't work on projects of any real size or complex ity. All of your products are fairly simple, single boxes.

Go design a missile some time. Or even a bridge over the Tacoma Narrows.

I can assure you that the hands that typed the code knew nothing about how airplanes fly. Neither did the feet that carried the person to the seat wh ere they typed the code or the rear that supported the person as they sat a nd typed.

Does everyone in your company know how the entire design process works or t he products work? Do your board layout people know how the products functi on? That's why companies have technicians and engineers. Both are needed, but why pay an engineer's salary to get technician work done?

Please provide the assurance. Your word alone is not enough.

(snip)

Indeed. Shall I call for the hands and have them type for you? Here they are...

"I am the hands that typed in the code for the Boeing 737 MAX MCAS processor. I know nothing about aircraft. I only type what the brain tells me to."

Is that good enough for you?

Rick C wrote in news:cb3bf0ea-0cdc- snipped-for-privacy@googlegroups.com:

What a stupid question.

I would not hired layout staff that were unable to understand the board they were laying out. It is REQUIRED, especially if analog signals are included.

Board layout people? More like PCB design engineers. It's not just about the schematic and what that engineer put into the circuit. Where the parts get laid and their traces matter.

It ain't just point a to point b.

No. Name the author of that comment and give the link to your source.

I don't think that any of my PCB layout people understood electronics. They do learn about trace widths and impedances and manufacturing issues, but I have to get them started on each layout, and I usually place+route the tricky parts myself.

My three best layout people were women with no engineering background. The Brat was/is the best, and she majored in softball and beer pong.

She did this one.

I thought the traces from the ADCs up into the FPGA were especially elegent. I let her pick the BGA balls for best routing.