bright@Data-IO.COM (Walter Bright) (02/02/89)
In article <286@proton.UUCP> proton!nusbaum@ucrmath.ucr.edu (R. James Nusbaum) writes: >Does anyone have any thoughts on the use of gcc (a relatively new >compiler as compilers go) vs. using Sun's C compiler in a medical >software project where software failure could cause loss of life? If your software fails, and causes loss of life, even if a particular bug in a compiler caused the problem, it is YOUR fault. All life critical software must be exhaustively and thoroughly tested. All life critical software must have a backup system. I worked for Boeing designing flight control systems. Since a failure meant we'd be picking bodies out of the mud, all software and electronics were considered to be inhabited by demons. This meant that all computer systems were assumed to be capable of doing the pathologically wrong thing at the wrong time, and so the system had to be designed so that this wouldn't cause an accident. A typical approach for software would be to have two parallel systems. Each system used a different microprocessor, a different algorithm, a different language, and different programmers. The two systems had to always agree, or they were automatically shut down. Also, the pilot was always able to override them. Boeing airplanes are a marvel of safety and reliability as a result of such attention to detail. I've worked in software for too long to risk my life on a single piece of software not having any bugs in it. Face it, compilers have bugs in them, and your software has bugs in it, and you don't bet lives on either.
bstrand@woods.unix.eta.com (Brad Strand) (02/03/89)
In article <1857@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >Boeing airplanes are a marvel >of safety and reliability as a result of such attention to detail. Too bad some of the engine control wiring wasn't tested as exhaustively as your software... Brad Strand, ETC-03J bstrand@woods.unix.eta.com ETA Systems, Inc. *** Racing to Win *** 1450 Energy Park Drive "Back off! I'm a scientist!" St. Paul, MN 55108 -- Bill Murray, Ghostbusters
glennw@nsc.nsc.com (Glenn Weinberg) (02/03/89)
In article <1857@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: > Boeing airplanes are a marvel >of safety and reliability as a result of such attention to detail. Yes, but... Not to be snide, but the recent FAA order requiring inspection of ALL Boeing jetliners made in the last 8 years for crossed wiring must make one wonder about just how much attention was really being paid to detail. Please don't get me wrong. I still think Boeing makes great airplanes. But this incident really brings into question the test methodologies used by Boeing. (They've apparently already discovered at least 4 planes with crossed wiring, not including the brand new 737-400 that recently crashed in Britain in which crossed wiring is merely suspected, and which triggered the FAA's recent concern.) So what does all this have to do with comp.lang.c? Just that no matter what the components of a complex system, be they computer hardware, software, or some mechanical part, adequate testing of the actual system is critical to ensuring performance--you can't depend on anything implicitly. This discussion should probably be moved to comp.risks. -- Glenn Weinberg Email: glennw@nsc.nsc.com National Semiconductor Corporation Phone: (408) 721-8102 (My opinions are strictly my own, but you can borrow them if you want.)
bright@Data-IO.COM (Walter Bright) (02/04/89)
In article <9598@nsc.nsc.com> glennw@nsc.nsc.com.UUCP (Glenn Weinberg) writes: >In article <1857@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >> Boeing airplanes are a marvel >>of safety and reliability as a result of such attention to detail. >Not to be snide, but the recent FAA order requiring inspection of >ALL Boeing jetliners made in the last 8 years for crossed wiring must make >one wonder about just how much attention was really being paid to detail. >But this incident really brings into question the test methodologies used >by Boeing. And you can bet that they will rework their testing to pick up this problem. Also, note that the wiring problem was in the manufacturing, not the design and my original posting was about the design. Aircraft engineering procedures are a result of a long history of things going wrong and methodologies developed to prevent human error. Past examples are crossing control cables, and crossing hydraulic lines. Electrical systems are newer, and thus there is less experience with them. Software is newer still. You ought to take a look at a cockpit with the skin off or the wheel well, at the thousands of wires in huge bundles there are. 1 defect slipped through. Is your software that good? I stand by my assertion that it's a marvel. P.S. I haven't worked for Boeing for years, and I'm not their spokesman. Also, I didn't write software for them, I did gearbox design (!).
gwyn@smoke.BRL.MIL (Doug Gwyn ) (02/04/89)
In article <1859@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >Also, note that the wiring problem was in the manufacturing, not the design >and my original posting was about the design. I'm not sure CPT Murphy would agree with you. Was the problem that the connectors were properly wired but plugged into the wrong jacks? That is precisely the problem that Murphy analyzed and described a fix for (key the connectors so they can't be inserted into the wrong jacks). By the way, I almost smoked a terminal recently by plugging a "modular connector" into the wrong jack (one being used for an entirely different purpose than the one near it).
rob@kaa.eng.ohio-state.edu (Rob Carriere) (02/05/89)
In article <9580@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I'm not sure CPT Murphy would agree with you. Was the problem that >the connectors were properly wired but plugged into the wrong jacks? >That is precisely the problem that Murphy analyzed and described a >fix for (key the connectors so they can't be inserted into the wrong >jacks). I'm not so sure that's applicable here. There is a rather large number of cables involved here, after all. We won't get anywhere by exchanging the problem of connecting the right connector to the right jack for the problem of connecting the right connector to the right cable! >By the way, I almost smoked a terminal recently by plugging >a "modular connector" into the wrong jack (one being used for an >entirely different purpose than the one near it). That's OK. There are quite a few buildings out there where those nice, safe, ``work in only one way'' electricity sockets have been wired the wrong way around. And that's done by ``professionals''! SR
henry@utzoo.uucp (Henry Spencer) (02/08/89)
In article <1857@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >A typical approach for software would be to have two parallel systems. >Each system used a different microprocessor, a different algorithm, >a different language, and different programmers. The two systems >had to always agree... One should remember, also, that independent development is not a guarantee of different algorithms. There is a strong tendency for programmers to produce similar solutions to similar problems. Keeping multiply-redundant systems truly independent requires systematic attention to be sure that the problem is indeed being tackled in different ways. -- Allegedly heard aboard Mir: "A | Henry Spencer at U of Toronto Zoology toast to comrade Van Allen!!" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu