If ever there is need for MISRA C then this is it!

Ignoring for a moment what the article says about the sad state of software development in general, this has no safety implications whatsoever.

The entertainment systems are totally isolated from the main flight control and navigation systems, they are not required to comply with the same standards, they are not subject to the same level of scrutiny, are not provided by the same vendors, etc. They can fail in any way (other than exploding or catching fire,) without affecting the airplane's safety.

Now if you really want to worry, do some research on the various Airbus fly-by-wire software problems...

Roberto Waltman

You know, if it was me (the mischievious type), I woulda done it repeatedly just to hear the grumbles again and again (many grumbles and one giggle).

flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...

How does MISRA-C stop guillible from believing tall tales?

flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...

Any reason to think it was written in C? Any suggestion as to which MISRA-C rule might help with this?

flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...

I call bullshit; complete, utter, unmitigated, no-excuses, no-holds- barred partially-digested plant matter liquid ordure gushing from the rectum of a male bovine directly into HTML format.

I ask all the engineers here - what is easier to design? A multihead system that drives 400 or 500 screens directly from a single CPU box running multiple threads on a [plurality of] CPUs, or 500 single-head systems that run a single game OS, like a Nintendo Gameboy, and communicate the voice stuff for the phone over a local network?

If you were designing the latter, why would you need to propagate a LOCAL game configuration parameter to all the units in the network? Why would this crash any of them?

I'm utterly certain this story is a completely bogus fabrication which someone is trying desperately to promote into an urban legend.

flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...

Don't hold back, chum, tell it like it is.

As an engineer, I take your point and agree with you.

As an engineering manager, though, I'm not sure. I've dealt with too many systems where the basic architecture was fecked. Perhaps somebody somewhere decided it had to be a single machine (weight constraints, perhaps?) and it went downhill from there...

Nowadays, when I meet clients, I get them to concentrate on requirements only (including cost/weight etc). I forbid them to think in terms of implementation until after they've seen my proposal (which usually manages to explain why the solution they were originally thinking of was a Really Bad Idea).

Steve

No... They *should be* in exactly the same way the software *should* be reliable....

I bet they said the same about the USS Yorktown

IT doesn't. Hopefully it just helps make software that little bit more reliable

If it was PC based infotainment it was probably C++ on an MS platform or Linux

It depends on what the actual course code problem was.

As per the USS Yorktown?

I understand that they tried that tactic with the USS Yourktown too. However that did have several cases where one PC brought down the entire ship.

Could you, please, give an example?

M.

Sure. One that comes up fairly regularly these days is web-enabled gadgets. Nothing wrong with that, but when the application is mission-critical, is in charge of some heavy-duty equipment, and has a tiny TCP/IP implementation, one wants more security than these gadgets can provide. This is not often an area that clients know enough about...

Another one is basing an embedded product on Windows "because it's easier". Enough said ;).

Steve

...

So you actually make them let you do your job. How do they react? I mean- do they try to interfere? Accept it? Try to pick up the subject anyway?

M.

I call it expectation management. At the initial planning meetings, I make it clear that we must separate requirements (including cost, of course) from implementation. I also invite - separately - their thoughts on implementation. I then generate a proposal that enumerates several implementations, with their pros and cons (including costs again), and invite them to decide. If their original idea is a bad one, it's clear why. So, it's ultimately their call. It's my job to make their decision informed.

Steve

flying.http://www.cashloopholes.co.uk/modules.php?name=Forums&file=viewtopic...

However, it doesn't seem all that likely and the OPs link has now died too. Still, full marks for effort though.

Not likely but it happened several times with the USS Yorktown...... Brought to a complete halt and had to be towed back to port several times.

...

Thanks.

M.