Perpetual motion controller

Don't talk about ejector seats. That was the most recent JAS 39 Griffin accident. The handle for the ejector seat (updated in the most recent edition of the plane) was found to be able to snag in the leg pads that gets inflated at high g loads.

One very surprised pilot suddenly found himself leaving a perfectly working plane in a hurry because he had been a bit hasty fitting the flight dress that morning.

In real life, just about everything can fail or go wrong. And do tend to fail. Twenty years of flying and then finding that the new and improved ejection seat intended to keep the pilot maximally safe could actually be his worst enemy.

Maybe our programming editors should contain the same type of pattern matching logic that Microsoft has in Excel. If you duplicate a formula to multiple cells, you will get a warning if one cell has absolute instead of relative addressing or references one step further or shorter than another cell. Your example should be quite easy to automagically analyze and flag as suspect.

Don't talk about ejector seats. That was the most recent JAS 39 Griffin accident. The handle for the ejector seat (updated in the most recent edition of the plane) was found to be able to snag in the leg pads that gets inflated at high g loads.

One very surprised pilot suddenly found himself leaving a perfectly working plane in a hurry because he had been a bit hasty fitting the flight dress that morning.

In real life, just about everything can fail or go wrong. And do tend to fail. Twenty years of flying and then finding that the new and improved ejection seat intended to keep the pilot maximally safe could actually be his worst enemy.

Maybe our programming editors should contain the same type of pattern matching logic that Microsoft has in Excel. If you duplicate a formula to multiple cells, you will get a warning if one cell has absolute instead of relative addressing or references one step further or shorter than another cell. Your example should be quite easy to automagically analyze and flag as suspect.

Per,

I've worked on widgets that had direct "human safety factors" involved, and I don't like doing that stuff all. So, Mr. Westermark, I can sympathize with your work.

It is scary to be responsible for the safety of people, when so many things can go wrong. Even if the root cause isn't directly tied to you, you still feel like your part could have been done better to avoid that other part you don't have control over.

Even though a 'commercial product' is just an iPhone, it could have life-saving applicability. Although it wasn't designed for that, the people writing the apps or firmware for it, should be aware its potential use.

The code should be treated like it has that life-n-death potential, and just telling yourself "well, its not like its a pacemaker and was not intended for that kind of use" doesn't absolve you of a basic responsibility to do it the best you can.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

Vince,
I have to say something related to your posts (I like them a lot). It shows that you have been working in this field for a long time; I look around me and I see budget cuts, mediocrity in programming language skills, and danger. danger everywhere. our society is in the hands of a handful of more or LESS skilled engineers who have the safety, future and welfare of our civilization in their (sometimes) capable hands. I see managers who are even more incompetent (not at my current employer, I must say). I am not very old yet, but I have seen my share. I have been working on safety critical system until a couple of months ago until I decided to leave because I felt that the level of incompetence was exceeding any tolerable measure, and that lives were literary at risk. It is good to know that some of us have the touch, still and despite of everything.

Thanks! (especially since I ramble on so much).

Don't you worry, I've had my share of *those* people you describe. The trick is to get yourself into a position, or place that doesn't have *those* people. I've had a few jobs in my life that horrified me, while I've had jobs that were the greatest thing since [ insert-your-favorite-thing here ].

I'm currently doing some work with people who have a clue, and boy-o-boy is that nice.

NOTE: All of the military related stuff have the cream of the crop R&D engineers on the teams. At some of these 'primes' an engineer would have to work there for 15-20 years on military/aerospace stuff before being allowed into an R&D team, so by the time they're On The Team, they're gooooood. Believe me, I've felt like the 'idiot' in the room, but somehow have managed to keep my head above water.

Even so, these engineers & scientists get it wrong sometimes. (for example, uh just look around everywhere). So when I see these Code-Monkeys doing their "isn't this the coolest code-fragment ever, cuz I do this thing in which you can't tell its doing it 'cuz I used the side-effect of that to do this and it is so tight nobody but 'smart-people' can figure it out" crap, I fear for my kid's lives.

Yet, while even these 'great places to work' are sweet, they can have their idiotic bosses, coworkers, *them*, etc (ALL of my current co-workers and bosses are super-cool), but you'll still get *them* from time to time. NEVER under-estimate their ability to screw you over though. You might think you're Sittin' Pretty and there is no way they can touch you---and then wow---suddenly 'stupidity strikes' and you get screwed.

NEVER EVER let *them* have the upper hand. Don't give them something to 'catch you on' or allow yourself to be the scape-goat.

Spot *them*, watch *them*, and avoid *them* as much as you can. And when you have to interact with *them*, make sure you are viewed as being a 'good guy' and doing the best you can FOR THEM. *Those* people will stab you in the back--and fast. Make sure your back isn't turned their way or provide them with a target.

I'm doing some live-saving bio-science stuff now. If I get it wrong, they just won't know they'll die... so since--in-effect--that outcome could be changed, I'm doing that whole Human Safety Factor cra--stuff again... Oh, we'll be doing the whole government compliance stuff too. Don't get much more fun than going through the Formal Qualification processes. Almost as much fun as writing the documentation.

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

P.S. When I fly on airplanes, I'm not worried. I just don't think about the zillion 'oops' that could be flying with me. I've seen these planes being manufactured, and it does make me feel 'more safe' knowing the amount of effort and quality they put into these airplanes. Uh, at least here in the USA. I'm not going to vouch for some "Biafra Airlines" plane though.

Vince: What are your definitions of TRUE and FALSE?

Are your explicit use of TRUE and FALSE in every test and assign a result of TRUE and FALSE having very specific values, possibly completely different from the "normal" true/false of the C compiler? Such that for example hardening the code from having a single bit error of a false/cleared variable giving a 100% conversion to true/set? Something like having

enum {
    FALSE = 0x5a,
    TRUE = 0xa5
};

If that is the case, then I would prefer the last if statement to be changed from:

if( lock_complete != FALSE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
   ...

to

if( lock_complete == TRUE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
 ...

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

"I'm not going to vouch for some 'Biafra Airlines' plane though."

Don't worry. Your guys fathers or grandfathers probably built those planes too. Just that the DC3 passed its best-before date somewhere when the ancients on this forum were still not born.

I'm not going to vouch for some "Biafra Airlines" plane though.

If I interpret the preliminary results of the board of investigation correctly, it was a software failure that killed 9 people in the Turkish Airlines crash in Amsterdam about 3 weeks ago. A faulty radar altimeter made the autopilot (that was landing the plane) think it was much closer to the ground (and to the runway) than it actually was. hence, the throttles were retracted reducing thrust to minimum. The plane stalled before the pilots could correct the situation, fell from an altitude of 500 meters. it was simply a miracle that the wreckage did not catch fire.

This thread has descended into total nonsense!

I wish civilian pilots would be a bit more distrusting.

It's one thing to rely on the autopilot at 30,000 feet, but during a landing it would be a lot better to keep the hands on the controls, while watching the ILS and ground, all the time prepared. There are so many other things the automatic landing systems can't detect - even if they have go-around quick-buttons for automatic automatically aborting a landing.

Having made a mental decision where the power should be reduced, the pilot would not need any extra response time if the automated landing system tries to reduce the power long before the pilots decided point.

But this problem exists everywhere. A lot of car companies have very advanced solutions to predict and automatically break before you run into stopped cars in front of you. But they are very scared of releasing the systems since they know that people will rely on them instead of using them as an extra guard. If professionals relaxes and puts all trust in automatic systems, how can a normal user be assumed to be better?

We already have a generation of people assuming that ABS breaks will guarantee the ability to break with maintained steering. The anti-skid systems of most newer (at least premium) cars will make people assume that they can't loose control of the car as long as they just hold the allowed speed limit.

"This thread has descended into total nonsense!"

Safety issues with embedded systems may actually be more on-topic for this forum than perpetual motion, even if safety issues may not win a Nobel price in physics.

What do you mean, "descended"?

A Perpetual Motion Machine is total nonsense!

en.wikipedia.org/.../Perpetual_motion_machine

Per,

Excellent catch:

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

It was just an example, and the code review guys might have caught me on that one. The use of the '!=' versus the '==' operator is something I practice and/or is a habit. At least one in which I would like to impart to others.

My defines for TRUE and FALSE are not the simple 0 and 1, or 0 and !0. if it is #defined, it usually contains 'many bits' (like your example of 0x5A/0xA5... or like 0xAAC3/0x553A, but it will also depend upon the processor architecture, instruction-set, etc. It is in a separate 'logic.h' or 'logic.inc' file.

And sometimes it is also #define TRUE (!FALSE) where FALSE = 0. Which I find 'lame.' Most of the time FALSE should be zero though, while TRUE is not simply a simple 1 or all 1 value:

0x0000 - 1 = 0xFFFF
0xFFFF + 1 = 0x0000

So you're only one bit away from a state change. (I'm sure there are many articles about this somewhere in the www).

It is a better construct to use a typedef/enum for flags (Boolean states) like TRUE & FALSE (where it is also assigned a value in the enum, and then actually declare the data-store as that type for your code.

// you pick your favorite name and/or 0 versus !0 thing
typedef enum {FALSE = 0x00, TRUE = !FALSE } boolean_typedef_name;

// not 1 bit away from state change on a 16-bit system
typedef enum {FALSE = 0x0000, TRUE = 0xC3A5 } Flag_Type;

// an 8-bitter: 8051
typedef enum {FALSE = 0x00, TRUE = 0xCA } Flag_Type;

Flag_Type Add_New_Code_Monkey( u8 *name )
{
    Flag_Type hired;

    hired = Check_Name( name, "Per" )

    return( hired );
}

But my point is, that Per is keenly aware of the potential to 'prefer' one state versus the other. Unfortunately, most 'bosses' are unaware of the difference between catching that and the code-monkey who can't. Thus during your performance review, you'll get chided over how many Post-It notes are on your monitor while Curious George in the cube next to you gets the kudos for 'neatness.' [If you're working at a place where the boss is that clueless, leave as soon as you can].

As far as my Biafra Airlines (Biafra == a country that existed from May of 1967 to January of 1970) comment, and the whole thing about flying is that although 'we' know how things can go wrong on very complex systems, when I fly, I don't get freaked out over it.

My wife on the other hand is very nervous when flying. Yet I have more of a reason that her to be nervous as I know more about the plane than she does. (While in flight, various noises that 'freak' passengers out, but they don't bother me at all since I have a clue on what that 'noise' means... and my wife knows that I know: she hates it when I used to say "Oh my! What was that noise?" just to get a rise out of her---I stopped doing that a long time ago).

And yes, the thread name is so very apt for the topic of the pursuit of Safety Related Issues of the non-Nobel Prize winning type.

(Funny how 'Nobel Prize' came up, as a coworker here knows, personally, several people who have received them. But, I'm starting keep my eye on *that* person though; 'cuz I'm just not sure about this one's 'stability' yet: a "Change" type personality).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I used to think that I was a fairly competent programmer.

However ... after noticing some of the responses on this thread I'm starting to wonder if I've got sufficient experience to even attempt to read them. I won't even pretend to say I can understand what it's all about!

Safety is a critical issue; quality and reliability are also important issues. From a technique perspective, everything does depend on how to qualify an engineer, and the sense of responsibility of the engineer itself. But there is something more than technique, I would say that, the golden age had been gone, and the human society is getting weaker and weaker. When the whole industry, decides to reduce the standard of acceptance, so to increase the production output, or to increase the business profit, there is not much things an individual can do.

It takes me almost more than ten years to learn that, "why so serious?", "people do things this way, so follow it."

For most people who are not very intellectual (like me), it is a career, not the whole life. But sure, good guys bear burdens; this is why good guys are good guys.

Finally and eventually, I become the person whom I dislike.

When I was going through flight training, my instructor and I were looking at the weather, trying to make the go/no-go decision. After a while of me trying to convince him that I should go fly, he turned to me and said "What am I going to tell the accident investigator?" Huh? What investigator?
"If you ball it in in this weather," he said, "they are going to come to me and ask why I let you fly. What am I going to tell them?"

I've tried to carry this idea into my software engineering career. We have all sorts of process, we have to meet the objectives of DO-178B, some days it seems like there's nothing but roadblocks keeping me from getting things done.

Every time I start getting frustrated at the burden of the process, I try to remind myself what my instructor said...If somebody turns a perfectly good airplane into a smoldering hole in the ground, and the NTSB comes to my door and wants to look at my software and my process, what am I going to tell them when they find that I skipped the re-verification after a minor change?

Just my $.02, and how I try to keep the process in perspective.