Disobeying jet engines - why?

Nope,

We do use a lot of their parts.

John

You most certainly are alllowed to talk about it. Most that I've seen have been Windows 2000. Haven't run into one yet that was XP.

I have run into some though that allowed touch screen access to functions. That was interesting.

My previous employer signed a confidentiality agreement that says otherwise, whether or not the party with whom they signed it has deployed any such machines yet. So no, I'm not.

Not at the core of the business. The fundamental software for many major institutions is based on (wait for it) IBM System/360 code, running on modern hardware platforms. The MS stuff is used for the client end such as tellers interface, because it's cheap and it doesn't matter if it bombs.

You still see native IBM-TSO screens running under command window from time to time. Applications like that are ancient, but essentially bombproof.

Dual redundant is widely used in moderately critical applications. It covers most process industries, for cases where a functional failure can result in major economic losses such as a plant shutdown. For things that go bang such as fired equipment, codes and standards nowadays mandate more elaborate setups such as triple redundancy.

The thing against higher orders of redundancy is that the sensors and actuators, which are generally the most likely failure points, also need to be addressed. The failure mode scenarios become very complex, things like trading off between spurious actuation and failure to initiate. And for the poor buggers that have to drive the thing (operators, pilots, whatever) it becomes a nightmare.

institutions is based on (wait for it) IBM System/360

client end such as tellers interface, because it's cheap

Yep, AS/400 and new derivatives are pretty strong in banks and other large government etc organizations. IBM is selling these things quite successfully, check out this year's business results.

time. Applications like that are ancient, but

They're investing a lot of effort into PC-AS/400 communication, they have all kinds of clients, Linux, windows, web based etc. Basically the machine just sits somewhere and you only go there to reset it or change the tape drive, all communication can be done via PC.

The local ATM machines around here all have OS/2, although this may be hard to maintain for new machines with additional functions so they probably had to abandon the idea eventually and move to a "more modern platform - as if" in USA.

In message , John Larkin writes

Since they went to manual (but still fly-by-wire) when the autopilot failed to deliver and the copilot who landed the plane gliding with the limited thrust and forward velocity he still had available just got over the boundary fence I somehow doubt this one is down to pilot error.

Thanks to him the investigation team has a complete aircraft to examine since he landed it more or less in one piece and with no loss of life.

Conjecture about why both engines failed to respond included quite a long list including fuel waxing, bird strike, software errors, and mechanical failures. We have to wait for the final report to find out the root cause.

Which is exactly how it should be. I trust properly designed hardware state machines a lot more than even the best commercial software.

I don't believe most software development today is actually good enough for civilian fly-by-wire. I have a bad feeling that some 777 code is in C++ and about 60% in the more robust Ada language. Hopefully non of it is anywhere near the mission critical stuff.

Regards,

On a sunny day (Fri, 25 Jan 2008 13:38:32 +1100) it happened Clifford Heath wrote in :

It seems far more likely to me that the bank knew what the French guy was doing, like 'OK do it, but if it fails we do not know about it'. Hedging is very dangerous, but it can also bring in huge profits. Bank took a chance, lost the lottery, and now needs somebody to blame.

Did not exactly something similar happen at Barclais years ago?

Barings bank, oldest bank in the UK, 230 years old, folded due to the loss. The guy wrote a book and a pretty good movie was made afterwards. In his case he was considered a hero until it turned out he was not earning millions but rather loosing zillions :)

I heard some speculations for the latest SG case that for this amount of loss to be generated his positions had to be in the order of 25-30 billions, hardly an amount a single person can setup without anyone noticing. Likely they knew what was going on and he would probably be considered a hero if the market wasn't working against him. Also, it is possible that closing of these positions (25-30 bil) contributed to the recent market dip. Another speculation is that the bank lots lots of this money in the credit-crunch and passed the blame onto this guy. Who knows.

You mean that they roll their own RTOS rather than buying one known to work. You can make a state machine controller with FPGAs and no OS, but a uP needs some sort of RTOS in order to function even if they don't call it that and it is integral with the rest of the code.

I recall a crash investigation a few years back (written up in Embedded Systems Design IIRC) where the crash was attributed to ECC software errors. Code analysis by a third party revealed something like 4000 errors (deviation from accepted high reliability software practice) in the code, many of them serious, resulting from a complete lack of adequate software and testing standards.

My guess is that the latest crash from loss of engine control will also be found to be a result of bad software which probably did not handle some unusual exception (such as a sensor failure) properly.

I don't consider what they do to be an "OS". There is no distinct separation between operating system and application code; no tasks are suspended partially-done; no task contexts are saved. I'm not absolutely sure, but I think there's no memory management and only one stack. I'll try to find out. The guys who do this have told me, emphatically, that there is no RTOS.

I do embedded realtime apps that have no OS. I've written a few RTOS's, but haven't needed to use one in a long time.

If the code is...

START: do thing1 do thing2 do thing3 goto START

where is the OS?

Some of the engines run fuel through the ecc before it's burned, to protect the ecc from temperature extremes.

John

On a sunny day (Fri, 25 Jan 2008 13:53:26 GMT) it happened Glen Walpert wrote in :

. You can make a state machine controller with FPGAs and no OS,

No, a micro controller needs no OS, and you can just write a state machine in software.

There are issues such as brown out that can do you in anyways though.

In message , John Larkin writes

I fear it will be found to be software or firmware at fault.

There may still be a kernel to arbitrate between interrupts and something like a watchdog timer to provide a means for restart and recovery in the even that the CPU itself latches up. I have know CPUs latch up (usually they were provoked to do so by application of large voltage spikes).

And you can get hit by lightning whilst trying to land. Although the airframe behaves as a pretty good Faraday cage.

The OS is the bit that should step in when one of thing1, thing2 or thing3 fails to complete. Most non-trivial embedded applications have some kind of RT kernel underpinning the allocation of resources.

I have even known one processor (specific batch) that would very very occasionally fail to obey the RTI instruction. Manufacturer denied it until faced with a logic analyser trace showing the event captured.

Fuel can get brutally cold on these long flights. One of the met office guys was talking about -70C or even lower exterior temperatures in the final stages of a transcontinental flight from China/Japan. Hence the concern that waxing in the remaining fuel might have taken out the engines simultaneously.

Losing one engine is unusual but losing both at the same time is exceedingly rare (unless you fly into a volcanic ash cloud, or a flock of birds). We have to wait and see what the investigators find.

Regards,

No it doesn't - unless you are going to redefine "an RTOS" as "any program whatsoever"! Which would render the term pretty useless, don't you think?

...and the idea is that generally each controller "knows" when it's failed? So there's seldom a scenario when one controller wants to do one thing and the other wants to do another?

Thanks for the background...

Snip .........

There was probably a sensor failure and 'engine control' thought it had already touched down. There is probably some code that limits engine output 'after touch down' when in 'landing configuration'. Just speculating :-|

Gerhard

There was probably some sensor failure and as a result 'engine control' was tricked into deducing that the plane had already touched down. It is highly likely that there is some code that limits engine output after touch down when controls are set for landing configuration. It might even be the result of multiple failures to have the conditions that get these system into a tis .... but it does happen.

Just speculating

Gerhard

I doubt it. You can do arbitrarily non-trivial apps with just state machines running in a loop. The only RTOS would then be a hardware watchdog timer.

The code blocks can themselves use whatever resources they want, assuming they are neither hostile nor stupid. The rare allocation-of-resources situation can be handled by code blocks locking out interrupts, or with simple flags.

If ever you assign a programmer to do a deep-embedded app, and he says "first, we'll have to write/buy an rtos", fire him instantly.

John

I love it! That one goes up on the bulletin board.