design rigor: electronics vs. software

Hardware designs are more rigorously done than
software designs. A large company had problems with a 737
and a rocket to the space station...

https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

I know programmers who do not care for rigor at home at work.
I did hardware design with rigor and featuring reviews by caring
electronics design engineers and marketing engineers.

Software gets sloppy with OOPs.
Object Oriented Programming.
Windows 10 on a rocket to ISS space station.
C++ mud.

 

[Rick C]

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

Hardware designs are more rigorously done than
software designs. A large company had problems with a 737
and a rocket to the space station...

https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

I know programmers who do not care for rigor at home at work.
I did hardware design with rigor and featuring reviews by caring
electronics design engineers and marketing engineers.

Software gets sloppy with OOPs.
Object Oriented Programming.
Windows 10 on a rocket to ISS space station.
C++ mud.

I think that is a load. Hardware often fouls up. The two space shuttle disasters were both hardware problems and both were preventable, but there was a clear lack of rigor in the design and execution. The Apollo 13 accident 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.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Winfield Hill]

Rick C wrote...

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.


--
Thanks,
- Win

 

On Fri, 10 Jan 2020 21:46:19 -0800 (PST), omnilobe@gmail.com wrote:

Hardware designs are more rigorously done than
software designs. A large company had problems with a 737
and a rocket to the space station...

https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

I know programmers who do not care for rigor at home at work.
I did hardware design with rigor and featuring reviews by caring
electronics design engineers and marketing engineers.

Software gets sloppy with OOPs.
Object Oriented Programming.
Windows 10 on a rocket to ISS space station.
C++ mud.

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.





--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.

"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

 

On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com>
wrote:

Rick C wrote...

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.

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



--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.

"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

 

Winfield Hill <winfieldhill@yahoo.com> wrote in
news:qvck970119k@drn.newsguy.com:

Rick C wrote...

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.

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.

 

[Winfield Hill]

DecadentLinuxUserNumeroUno@decadence.org wrote...

Winfield Hill wrote:

Rick C wrote...

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.

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

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".


--
Thanks,
- Win

 

On Sat, 11 Jan 2020 06:57:58 -0800, jlarkin@highlandsniptechnology.com
wrote:

On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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 <winfieldhill@yahoo.com> wrote in news:qvcpg901bm2
@drn.newsguy.com:

DecadentLinuxUserNumeroUno@decadence.org wrote...

Winfield Hill wrote:

Rick C wrote...

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.

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

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".

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.

 

On Sat, 11 Jan 2020 17:32:45 +0200, upsidedown@downunder.com wrote:

On Sat, 11 Jan 2020 06:57:58 -0800, jlarkin@highlandsniptechnology.com
wrote:

On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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.

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?




--

John Larkin Highland Technology, Inc

The cork popped merrily, and Lord Peter rose to his feet.

"Bunter", he said, "I give you a toast. The triumph of Instinct over Reason"

 

upsidedown@downunder.com wrote in
news:aaqj1f52dd6m9j2dii7fm69ve9d1d9ocse@4ax.com:

On Sat, 11 Jan 2020 06:57:58 -0800,
jlarkin@highlandsniptechnology.com wrote:

On 11 Jan 2020 05:57:59 -0800, Winfield Hill
winfieldhill@yahoo.com> wrote:

Rick C wrote...

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.

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

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.

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.

 

[Winfield Hill]

DecadentLinuxUserNumeroUno@decadence.org wrote...

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

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.


--
Thanks,
- Win

 

[Rick C]

On Saturday, January 11, 2020 at 9:47:19 AM UTC-5, jla...@highlandsniptechnology.com wrote:

On Fri, 10 Jan 2020 21:46:19 -0800 (PST), omnilobe@gmail.com wrote:

Hardware designs are more rigorously done than
software designs. A large company had problems with a 737
and a rocket to the space station...

https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-737-max-software-outsourced-to-9-an-hour-engineers

I know programmers who do not care for rigor at home at work.
I did hardware design with rigor and featuring reviews by caring
electronics design engineers and marketing engineers.

Software gets sloppy with OOPs.
Object Oriented Programming.
Windows 10 on a rocket to ISS space station.
C++ mud.

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?

There is a very well known rule about software (assuming you include FPGA HDL 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 seldom has bugs when run in an FPGA. Yes, even "seldom" does not preclude bugs, 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.

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.

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

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.

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 get right the first time by applying requirements and evaluating to those requirements.

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

In your organization.

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.

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 and testing. Ok, but that won't work on projects of any real size or complexity. All of your products are fairly simple, single boxes.

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

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

 

[Rick C]

On Saturday, January 11, 2020 at 9:58:06 AM UTC-5, jla...@highlandsniptechnology.com wrote:

On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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 where they typed the code or the rear that supported the person as they sat and typed.

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

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

 

[John S]

On 1/11/2020 10:52 AM, Rick C wrote:

On Saturday, January 11, 2020 at 9:58:06 AM UTC-5, jla...@highlandsniptechnology.com wrote:
On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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 where they typed the code or the rear that supported the person as they sat and typed.

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

(snip)

 

[Rick C]

On Saturday, January 11, 2020 at 12:07:32 PM UTC-5, John S wrote:

On 1/11/2020 10:52 AM, Rick C wrote:
On Saturday, January 11, 2020 at 9:58:06 AM UTC-5, jla...@highlandsniptechnology.com wrote:
On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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 where they typed the code or the rear that supported the person as they sat and typed.

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

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.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

 

Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:cb3bf0ea-0cdc-42d7-b402-90ff2190683b@googlegroups.com:

I can assure you that the hands that typed the code knew nothing
about how airplanes fly.

Then you know abso-fucking-lutely nothing about aircraft
manufacturers' engineering staff.

 

Rick C <gnuarm.deletethisbit@gmail.com> wrote in news:cb3bf0ea-0cdc-
42d7-b402-90ff2190683b@googlegroups.com:

> Do your board layout people know how the products function?

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.

 

[John S]

On 1/11/2020 11:16 AM, Rick C wrote:

On Saturday, January 11, 2020 at 12:07:32 PM UTC-5, John S wrote:
On 1/11/2020 10:52 AM, Rick C wrote:
On Saturday, January 11, 2020 at 9:58:06 AM UTC-5, jla...@highlandsniptechnology.com wrote:
On 11 Jan 2020 05:57:59 -0800, Winfield Hill <winfieldhill@yahoo.com
wrote:

Rick C wrote...

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.

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

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 where they typed the code or the rear that supported the person as they sat and typed.

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

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?

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

 

[John Larkin]

On Sat, 11 Jan 2020 18:08:32 +0000 (UTC),
DecadentLinuxUserNumeroUno@decadence.org wrote:

Rick C <gnuarm.deletethisbit@gmail.com> wrote in news:cb3bf0ea-0cdc-
42d7-b402-90ff2190683b@googlegroups.com:

Do your board layout people know how the products function?

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.

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.

https://www.dropbox.com/s/w7ulg68pvni3hpf/Tem_Plus_PCB.JPG?raw=1

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


--

John Larkin Highland Technology, Inc trk

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com