Real time scheduler C

I'm a bit puzzled by your stated position.

If you're saying that Windows is fine for non-critical applications, fine. I don't think anyone would disagree with you.

If you're saying that Windows is fine for safety-critical apps, you're just plain wrong. You've given examples of reasons why Windows becomes unstable (people fooling with them), but there are plenty of other reasons: 3rd-party drivers for NICs and graphics cards spring to mind. And if the Windows machine is connected to a network, you're in real trouble.

Even with a plain-vanilla Windows machine with no 3rd-pary drivers, and no network connection, only a fool would trust his life to it. This is, I think, unarguable - it's just the wrong platform to use.

Steve

formatting link

Reply to
Steve at fivetrees
Loading thread data ...

"Steve at fivetrees" schreef in bericht news:xMCdnT snipped-for-privacy@pipex.net...

I

just

3rd-party

Well, I suppose you shouldn't use cheap China NICs but choose proven industrial standard NIC's and their drivers. And none of those 'game' cards which have driver updates every other week.

Why is that? I would think you would not allow too many protocols running, and remove all applications except your own stuff. No internet explorer on this machine... No outlook express either.

All other platforms are dangerous too, in the hands of fools. And even in the hands of experts things go wrong. I assume the examples that Chris gave, were all products of experts.

--
Thanks, Frank.
(remove 'q' and '.invalid' when replying by email)
Reply to
Frank Bemelman

Yes, there is a cost of using the bloodhounds to keep the end users from installing games etc. to the systems, but putting the systems behind locked doors without any user interface connections helps a lot:-).

This was a real problem in the late 1990s, but it seems that the 3rd party manufacturers have recognised the problem.

As long as only known computers are in the network, there is no problem.

There is going to be a severe mess if you connect the system directly to internet or allow infected laptops into the network will definitively cause problems. Using non-RJ-45 connectors often helps to reduce the latter problem :-).

I am comfortable only with electro mechanical relays, mechanical interlocks and spring loaded safety valves in boilers etc..

Using Windows, realtime OS xxx or even 74xx series TTL is suspicious to me, since a simple lightning hit (not to mention NEMP) could cause havoc to other system.

IMHO the most important thing in designing safety critical system is that you should *not* rely on a single physical phenomenon, but instead use electronics, optics, magnetics, pneumatics, hydraulics etc. in independent safety systems.

Paul

Reply to
Paul Keinanen

Erm... My desktop machine here has an in-built Gigabit NIC. I've had to disable it; even with plain-vanilla Microsoft drivers, the NIC goes deaf rather too regularly. My son has a games machine with a high-end ATI graphics card (around £350-worth); he tells me the drivers are dreadful and are known to be unstable. To be fair, they seem to have improved a bit recently - but for about a year my son refused to use the latest drivers, instead using old and trusted versions...

You were saying? ;)

Yes, agreed. Again, to be fair, this is true generally. However I'm not sure I'd trust a Windows machine to be secure without an external hardware firewall. I *would* trust e.g. OpenBSD.

Yes, I agree with all of that. However - I stand by my original point: Windows is simply not a suitable platform for running safety-critical apps on. It wasn't designed to be. And why would anyone want to, when there are far better choices?

I'm somewhat happier running WinCE in such cases, since one can actively choose *which* parts of the OS one installs. But with desktop Windows, there's just too much hidden going on... and again, why risk it?

Steve

formatting link

Reply to
Steve at fivetrees

Is this NIC known to work reliably in any other operating system, i.e. is there a problem with the HW or driver ?

High-end graphics card are targeted for the gaming market, in which speed (frame rate) seems to be only selection criterion. All manufacturers in this business area try to squeeze out even just one more fps, by ignoring any "unnecessary" checks and the programmers add often quite a few new errors of their own in every version.

The latest drivers are just beta versions to boost better performance than the competitor and also spread to a large number of different platforms to find any bugs or compatibility problems. Most users seem to be eager beta testers :-).

The last "stable" version arrive much later than the corresponding beta version with the same features.

When building mission or safety critical systems in any operating system, you can not just throw together components with compatible connectors, throw in any random OS version and throw in the required application software and any other nice to have software into the system.

You really have to specify what interface cards to use (i.e. both the card and the driver is reliable), specify which OS version to use and specify exactly what programs to run on the system. Sure, it takes several months to get a new system to market even if the application software is ready.

Paul

Reply to
Paul Keinanen

I'm not sure, but I'm assuming driver - mainly because during the few months I tried to use it, Microsoft issued a driver update for the NIC every month. I've forgotten what the NIC chipset is; but it's a Gigabyte motherboard - I've used quite a few of their products, and not had any trouble before.

However: that's also a valid point. I've had quite a few weird chipset problems with PC hardware over the years (including on hardware produced specifically for the embedded systems market). I'm not sure I trust that either ;).

I *knew* I'd get jumped on for that example ;). You're right - such a card would be a *really* bad choice for safety-critical apps in any case. I was making a point - badly ;).

[FYI: my son recently had trouble with 2 ATi graphics cards. Both were expensive, and both started getting flakey after a few minutes of operation. We eventually traced the problem to heat. On one of them, I added a HUGE aftermarket fan/heatsink assembly, and added heatsinks on all the RAM devices. It improved things a little. We eventually got the thing running smoothly by leaving the case open, and putting two (two!) large domestic fans right beside it, blowing fresh air directly into the case. Gah.]

Steve

formatting link

Reply to
Steve at fivetrees

In article , larwe writes

Airbus 320

It killed the crew at an air show directly because of the control software.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris Hills

This, actual, was the software in the captain's brain: Too slow, too deep, too much flaps with too less engine's power. This had to lead to a controlled flight into the wood (the so called crash).

But you are right with A320 in Warszawa (Poland, the copilot died, as I remember) and the Lauda Air with the deployed engine reversal at cruise flight level above Thailand or so (more than 100 people died).

Reply to
Bodo Rzany

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.