Hacker News Reader

Comment by TallGuyShort | Hacker News Reader

In spaceflight, does 'anomaly' ever refer to something other than an explosive fireball? Because I've heard that term used for rocket explosions and I get that vibe from this announcement, but... But could it be that the computer just tanked and now they're going through a core dump? Would that be an 'anomaly'?

View on HN

From a NASA systems engineering handbook:

>Anomaly: The unexpected performance of intended function.

Good or bad, major or minor, an anomaly is when reality does not meet engineering design and expectation. It just happens that in spaceflight the most active time is the most dangerous time and most anomalies result in fireballs when your engine is lit as there is not much room at all for error.

I believe the motivation for referring to things as anomalies is to forestall any rush to judgement about an unexpected event. AKA something 'bad' happened.

Old memory from the 80's an engineer mentioned that he went down to the lab and found an unhappy test tech. Guy was testing a new pressure sensor and it wasn't able to make 10,000 full cycles without blowing the diaphragm. Turned out the test setup was shock loading the pressure sensor. He was surprised it was almost passing. The solution was a rate limiting valve in the test setup. There was nothing wrong with the pressure sensor.

There is a great write up from one of the guys that developed the thrusters for the Apollo program. They had problem where you could get layers of frozen oxidizer and fuel in the inside of the nozzle. Which would then go explode and shatter the nozzle. The solution was to operate the thrusters so that didn't happen.

Currently reading On The Shoulders of Titans about the Gemini program. It gets slammed for being very poorly edited & formatted, etc. but it's dirt cheap if you can see past that. Quite a good collection of interesting engineering problems & solutions like that, and some very good lessons on how (and how not) to run major engineering projects (but as the reviews will tell you, it's just a human-readable series of events drawn from memos and calendars, etc - there's little analysis or real commentary). One of my favorites is that the maneuvering & attitude thrusters used ablative cooling, but ablated way too fast. They got incremental improvements by messing with the orientation of the laminated layers and other tweaks, but the real break through was squirting fuel down the inner walls of the cone immediately prior to ignition: got something like 4x the previous engine life and double their target.

Absolutely. Those sorts of anomalies happen routinely. They just tend to get less public attention than anomalies that involve fire and loud noises.

A fun example: https://en.wikipedia.org/wiki/Pioneer_anomaly

Here is one that just pushed a launch out:

https://www.rferl.org/a/soyuz-rocket-anomaly-to-delay-u-s-sa...

usually means something rather more mundane than a fireball. basically anything that happened that you didn't want to happen is an anomaly.

10 years ago the folks putting your reaction wheels together botched it, and now they're acting slightly weird? anomaly.

you charged your batteries too hard for years because you thought "max" was a great setting for your battery chargers, and now they're failing? anomaly.

In spaceflight, does 'anomaly' ever refer to something other than an explosive fireball?

Strangely enough, yes: the satellite guys use 'anomaly' to describe the (angular) position of a body in its orbit. I've never heard where the term originated in that context.

I was curious about that myself. In astronomy, there is the mean anomaly, and the "true" anomaly. The mean anomaly is relative to a circle with the same period as the actual object, while the true anomaly is relative to an ellipse. A few minutes of Googling suggests that originally, the term anomaly came from the discrepancy between predictions of orbits assuming they were circular and observations, and it was something that was explained by epicycles in the time of Ptolemy, almost 2,000 years ago. So yes, it comes from the same concept of an anomaly.

Incidentally, according to what I was just reading, epicycles in principle can be used to approximate any curve if you pick them appropriately. Choosing them is related to fourier analysis which of course hadn't been developed yet. When you hear about it in grade school, it's presented as this dumb thing that doesn't make sense, but it was really not a terrible solution.

Ariane had an anomaly where satellites ended in the wrong orbit. No booms involved.

Ideally, computers inside rockets don't crash. The software should be that good when you're letting it handle tons of explosive fuel. Then again, Ariane 5 did happen...

That's the idea. I'm working on flight software for Orion, and there are many levels of redundancy, both in design and process, that are put into the software architecture. It's extremely expensive, but flight software is still a drop in the bucket compared to mechanical, propulsion, and electrical systems. It should have an expected failure rate much lower than the physical systems, and should never be on the critical path. We're not doing fancy stuff, it's just gotta be robust and fault tolerant.

> just

The deadpan delivery really does it.

Yeah well, it's definitely not trivial. I just mean that most of the problems we're implementing have been solved decades ago (inverse kinematics, control, comms, etc). When you actually need to get all of those functions working in a hard real-time system, of course there are enormous engineering difficulties. In my limited experience, these mostly manifest as extensive testing and formal verification, to the extent to which that is possible.

Check out NASA Core Flight System if you're curious, it's an in-house framework and abstracted OS layer meant to support hard real-time flight systems.

Definitely will do that, thank you for the pointer. Reliable software design is something I've been interested in for a very long time and it is amazing (to me, at least) how much we already know and yet refuse to put into practice. I think a big part of this is that speed is sexy and reliability is not.

Yes, but there's a big difference between "the spacecraft blew up in the test harness" and "all of the stack traces were recorded and a CS intern is currently testing a patch and we'll be back in business by Monday". The press-release didn't really indicate how serious of a setback this anomaly is. Although now the article has been updated with "smoke seen for miles" which wasn't the case before.

Ariane 5's computers never crashed. At least, not until they hit the ground. They operated flawlessly and ran the software the way they were supposed to.

The software did guide the rocket off the intended path and it would have crashed if range safety hadn't stepped in at that point.

Computers do what you tell them to, not what you want them to do.

Reply on news.ycombinator.com