design rigor: electronics vs. software

I forgot to add that the act of building a formal model in AADL from the requirements forces one to *think* about system wide impacts and do analysis on the architectural model. Requirements are written in English, one of the most widely used tool is MSWord. another is DOORs

Thanks. I feel a bit like I'm drinking from a fire hose, which is always my preferred way of learning stuff.... I'd be super interested in an accessible presentation of methods for sanity-checkin high-level system requirements.

Being constitutionally lazy, I'm a huge fan of ways to work smarter rather than harder. ;)

Cheers

Phil Hobbs

It's a controller for a deep-UV MOPA laser, for IC lithography. The pulse rate is about 6 KHz. Way less than $10K.

The management of two AOA sensors was insane. Fatal, actually. A programmer should understand simple stuff like that.

It is unrealistic to expect programmers to understand sensor reliability. That is the job of the people specifying the system design and encoding that in the system specification and the software specification.

Programmers would have zero ability to deviate from implementing the software spec, full stop. If they did knowingly deviate, it would be a career ending decision - at best.

Aerospace engineers have lost their pension for far less serious deviations, even though they had zero consequences.

Tom Gardner wrote in news:ooWSF.30854 $ snipped-for-privacy@fx39.am:

I think it would be nice to have a full understanding of ANY failure modes ANY transducer I would be programming the actions of others from would have in its operation. So I would at least want to be at those meetings. ;-)

So, in the 737 max scenario, I would want to know about it (atitude sensor) sticking from icing up. As far as I know, the actual encoding in them is a simple slot mask on a disc (optical encoder wheel), which can resolve to a couple ticks per degree with ease, more if a higher resolution were needed.

I would place two wheels on each and a 'kicker' device that turns it through its full travel and then releases it for reading again (and maybe a heater for the bearings). That way it could be checked for failed/free operation while in flight.

I just got bitten by a 'feature' of LTSpice XVII, I don't remeber IV having this behaviour but I don't have it installed any more:

If you make a tweak to a previously working circuit, which makes the netlister fail (in my case it was an inductor shorted to ground at both ends), it will pop up a warning to this effect, and then *run the sim using the old netlist*.

It will then allow you to probe around on the new schematic, but the schematic nodes are mapped onto the old netlist, so depending on what you tweaked, what is displayed can range from slightly wrong to flat-out impossible.

Anyone else seen this?

Gee, Mr. Gardner, you're so manly--can I have your autograph? ;)

Nobody's talking about coders doing jazz on the spec AFAICT. Systems folks do need to listen to them, is all. If they can't do that because they don't understand the issues, that's a serious organizational problem, on a level with the flawed spec.

Fortunately that's illegal over here, even for cause.

Cheers

Phil Hobbs

Job ending, not career ending. I wouldn't code something that was obviously dumb and dangerous.

If someone quits Boeing over an issue like this, it doesn't end their career. They can find a better employer.

If an interviewer asked "why did you leave Boeing?" I'd tell them.

How can a company take away an earned pension? Because an engineer did something ethical? Sounds like a giant settlement would follow; quadruple that pension.

Given dual sensors, why would any sane person decide to alternate using one per flight?

A programmer would have to be awfully thick to not object to that.

Well, by all accounts there were/are serious organisational problems in Boeing. Those are probably a significant contributor to there being a flawed spec.

I was gobsmacked when I heard that, and don't understand it. But then I don't even understand the concept of pension "vesting".

Nonetheless, that's what his supervisor (who did his utmost to save him) in Los Angeles said.

Agreed, but resigning is very different to deliberately mis-implementing a spec.

In such circumstances I hope I would resign, but there have been time in my life when that would have been impossible.

I don't understand that either.

As I remember it, the conscientious worker was placed under time pressure. Signoff required a signature and his personal official stamp. He signed in advance of completing the work, but did not affix his stamp.

A passing body saw that document, reported it, and the process ground inexorably from that.

Grossly disproportionate an unfair? You betcha, but so what.

Agreed. Especially given the poor reliability of AoA sensors.

The people that write and signed off that spec bear a lot of responsibility

The programmer's job is to implement the spec, not to write it

They may have objected, and may have been overruled.

Have you worked in large software organisations?

Not in, but with. Most "just do our jobs", which means that they don't care to learn much about the process that they are implementing.

And the hardware guys don't have much insight or visibility into the software. Often, not much control either, in a large organization where things are very firewalled.

Recipe for disaster.

the

't

o do

Somewhat less significant, I was doing a bus timing analysis of an interfac e between a new board and existing boards in a new radio which was not yet in full production. I found a small timing spec miss with a Flash memory p art. I tried to report it to the lead engineer but the response I got was "the unit has passed acceptance testing", as if that meant there were no er rors in the radio.

I had been around and around with the company's hostile work environment an d employees working around the system rather than doing what needed to be d one. I let the matter drop. Not that it was particularly likely to cause a problem in the radio... but that was certainly a possibility, even if ver y, very small. These were military radios and everyone stressed how import ant it was that they work under all conditions. But the company had worn m e down...

Companies suck. I won't be an employee again.

This is a controller for a MOPA deep-UV laser, for IC lithography. The pules rate is about 6 KHz.

the

n't

ho do

Not really an issue of firewalls. Your company does the same thing as we h ave pointed out. The 'Brat' doesn't look over your shoulder when you desig n the circuits, she just routes the board the way you tell her. That's not a firewall. That's delegation of responsibility. Same in larger companie s.

Unlike many small companies, large ones have changed significantly over the decades. While many small companies are run by one or a small number of a utocrats, large companies set u formal processes to make important decision s. The design process virtually always includes peer review. They try har d to not make mistakes, even small ones.

But there are many opportunities to make mistakes and we don't always avoid every one of them. Sometimes we push the boundaries and find our iceberg.

Seen that, and it even occurs within software world:

-analysts lob spec over wall to developers

-developers lob code over wall to testers

-developers lob tested code over wall to operations

-rinse and repeat, slowly

"Devops" tries to avoid that inefficiency.

I've turned down job offers where the HR droids couldn't deal with someone that successfully straddles both hardware and software worlds.

Yup, as we've seen.

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 accid ent was hardware. The list goes on and on.

id the cause of the accident was improperly coded software.

Technically, one of those shuttle disasters was due to management not liste ning to their engineers, including those at Morton-Thiokol, that the booste r rocket O-Rings were unsafe to launch at cold temperature.

I don't consider that to be a "hardware problem" so much as an arrogantly s tupid decision to launch under known, unsafe conditions.

As for the tiles (2nd shuttle loss), I am weirdly reminded of the Siegfried & Roy Vegas act with the white lions and tigers. They insured against eve ry conceivable possibility (including the performance animals jumping into the crowd and causing a panic!). Everything that is, except the tiger vic iously attacking Roy Horn on-stage.

You think you could see that coming..., or at least have a plan (however re mote the possibility)?

With the shuttle heat tiles, NASA had to replace a lot of those after every flight. Did they never see the tiger?