From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,LOTS_OF_MONEY, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,885dab3998d28a4 X-Google-Attributes: gid103376,public From: Alan Brain Subject: Re: Ariane 5 failure Date: 1996/10/03 Message-ID: <32546A8F.75D8@dynamite.com.au> X-Deja-AN: 186896210 references: <96100112290401@psavax.pwfl.com> <32531A6F.6EDB@dynamite.com.au> <3252B46C.5E9D@lmtas.lmco.com> content-type: text/plain; charset=us-ascii organization: @Home mime-version: 1.0 reply-to: aebrain@dynamite.com.au newsgroups: comp.lang.ada x-mailer: Mozilla 3.0 (Win16; I) Date: 1996-10-03T00:00:00+00:00 List-Id: Ken Garlington wrote: > So what did you do when you needed to build a system that was bigger than the > torpedo hatch? Re-design the submarine? Nope, we re-designed the system so it fit anyway. Actually, we designed the thing in the first place so that the risk of it physically growing too big and needing re-design was tolerable (ie contingency money was allocated for doing this, if we couldn't accurately estimate the risk as being small). > Oh for the luxury of a diesel generator! We have to be able to operate on basic > battery power (and we share that bus with emergency lighting, etc.) Well ours had a generator connected to a hamster wheel with a piece of cheese as backup ;-).... but seriously folks, yes we have a diesel. Why? to charge the batteries. Use of the Diesel under many conditions - eg when taking piccies in Vladivostok Harbour - would be unwise. > Exactly. You build a system that has slack. Say, 15% slack. Which is exactly > why the INU design team didn't want to add checks unless they had to. Because > they were starting to eat into that slack. I'd be very, very suspicious of a slack like "15%". This implies you know to within 2 significant figures what the load is going to be. Which in my experience is not the case. "About a Seventh" is more accurate, as it implies more imprecision. And I'd be surprised if any Bungee-Jumper would tolerate that small amount of safety margin using new equipment. Then again, slack is supposed to be used up. It's for the unforeseen. When you come across a problem during development, you shouldn't be afraid of using up that slack, that's what it's there for! One is reminded of the apocryphal story of the quartemaster at Pearl Harbour, who refused to hand out ammunition as it could have been needed more later. > What if your brand new CPU requires more power than your diesel generator > can generate? > What if your brand new CPU requires a technology that doesn't let you meet > your heat dissipation? But it doesn't. When you did your initial systems engineering, you made sure there was enough slack - OR had enough contingency money so that you could get custom-built stuff. > Doesn't sound like you had to make a lot of tradeoffs in your system. > Unfortunately, airborne systems, particular those that have to operate in > lower-power, zero-cooling situations (amazing how hot the air gets around > Mach 1!), don't have such luxuries. I see your zero-cooling situations, and I raise you H2, CO2, CO, Cl, H3O conditions etc. The constraints on a sub are different, but the same in scope. Until such time as you do work on a sub, or I do more than just a little work on aerospace, we may have to leave it at that. > > Usually such ridiculously extreme measures are not neccessary. The > > Hardware guys > > bitch about the cost-per-CPU going through the roof. Heck, it could cost > > $10 million. > > But if it saves 2 years of Software effort, that's a net saving of $90 > > million. > > What does maintenance costs have to do with this discussion? Sorry I didn't make myself clear: I was talking development costs, not maintenance. > I've never had a project yet where we didn't routinely cut it that fine, > and we've yet to spend the big bucks. Then I guess either a) You're one heck of a better engineer than me (and I freely admit the distinct possibility) or b) You've been really lucky or c) You must tolerate a lot more failures than the organisations I've worked for. > If you're used to developing systems > with those kind of constraints, you know how to make those decisions. > Occasionally, you make the wrong decision, as the Ariane designers discovered. > Welcome to engineering. My work has only killed 2 people (Iraqi pilots - that particular system worked as advertised in the Gulf). There might be as many as 5000 people whose lives depend on my work at any time, more if War breaks out. I guess we have a different view of "acceptable losses" here, and your view may well be more correct. Why? Because such a conservative view as my own may mean I just can't attempt some risky things. Things which your team (sometimes at least) gets working, teherby saving more lives. Yet I don't think so. > And, if you had only got 20MB per second after all that, you would have > done...? 20 MB? First, re-check all calculations. Examine hardware options. Then (probably) set up a "get-well" program using 5-6 different tracks and pick the best. Most probably though, we'd give up: it's not doable within the budget. The difficult case is 150 MB. In this case, assembler coding might just make the difference - I do get your point, BTW. > Certainly, if you just throw out range checking without knowing its cost, > you're an idiot. However, no one has shown that the Ariane team did this. > I guarantee you (and am willing to post object code to prove it) that > range checking is not always zero cost, and in the right circumstances can > cause you to bust your budget. Agree. There's always pathological cases where general rules don't apply. Being fair, I didn't say "zero cost", I said "typically 5% measured". In doing the initial Systems work, I'd usually budget for 10%, as I'm paranoid. > Unfortunately, cost is not the only controlling variable. > > Interesting that a $100K difference in per-unit cost in your systems is > negligible. No wonder people think military systems are too expensive! You get what you pay for, IF you're lucky. My point though is that many of the hacks, kludges etc in software are caused by insufficient foresight in systems design. Case in point: RAN Collins class submarine. Now many years late due to software problems. Last time I heard, they're still trying to get that last 10% performance out of the 68020s on the cards. Which were leading-edge when the systems work was done. Putting in 68040s a few years ago would have meant the Software would have been complete by now, as the hacks wouldn't have been neccessary. ---------------------- <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM ---------------------- o OO*O^^^^O*OO o oo oo oo oo By pulling Maerklin Wagons, in 1/220 Scale