zlacker

>>belter+(OP)
In short, it was remote bricked, by giving it commands to rotate a bit. After successfully executing those commands - no further commands could be received, as now the antennas are not facing earth anymore.

But luckily it automatically readjust itself to earth automatically every half year exactly for these events. So on 15.10 we will know, if it is really lost. In either case, the end of its mission is near anyway, because the nuclear batteries are near its end.

edit: Nasa has a blog post on this https://blogs.nasa.gov/sunspot/2023/07/28/mission-update-voy...

>>hutzli+79
Amazing that someone thought up a solution to a hypothetical problem 46 years ago, then fired it 30 billion km away

>>swarni+Ti
Aerospace has a very high quality standard compared to other industries.

Lots of formal processes capture what would otherwise be informal design decisions elsewhere. In this case, they probably have reams of pages detailing a failure mode effects analysis (FMEA). One mode is “oops, we sent the wrong command” and the document would define the specific design mitigation(s) for that outcome until it reaches an accepted risk threshold.

>>bumby+Tr
FMEDA probably. And in recent times, fault tree analysis seems to be better for complex systems.

>>aether+gp2
As far as I’m aware, no NASA standards call for FMEDA. It doesn’t mean a project manager couldn’t levy it, but it’s not often that a contractor adds additional requirements to a gov funded build.

>>bumby+DN2
FMEA relies on a really smart person anticipating all the different combinations of failures worth exploring (NxM), not just N or M.

Some failures are fairly common, and individual failures might be fairly inert but have more serious consequences if they are cascaded with another specific failure.. for example, cruise control enable + failure of steering wheel control pad _and_ previously undetected failure of brake sensor/brake light circuit = cruise control stuck ON. Actually, this failure is inert if the cruise control is OFF when it happens. Contrived example but you get the idea ...

I have seen a lot of FMEDA (and other tool) use lately to combat concerns with cascading failure, but not sure what's currently standard at NASA or how they deal with this. I would think cascading failure would be their expected scenario on a 10+ year unmanned mission.

>>aether+WU2
NASA STDs, handbooks, guidebooks, NPDs and NPRs are all open-source. They don’t mention FMEDA, and they don’t generally have a detectability column in their FMEA. IMO they are a little outdated

>>bumby+5G3
I've done for NASA what they were calling FMECA and FTA for a subsystem. They had a lot of freedom to tailor the analysis to the situation, and the end result didn't quite match anything established. We addressed detection in some of the FMECA columns which are not traditionally for detection; and events in some of the FTA. It was a contortion of terminology and format to modernize and maximize the value of the analysis given their limited resources and the bureaucracy of what they were allowed/required to do on paper.

Here's how I would describe the possible analysis approaches in broad terms, avoiding terminology that NASA does not officially use.

- Start from the hazard of being pointed in the wrong direction and work backwards to identify the causes, forming a tree.

- Start from the event of commanding the wrong direction and work forwards to identify mitigations or the lack thereof, also forming a tree.

- Start from looking at a component or subsystem, list all the ways it can fail without regard for the application. Then consider the application and work up towards the causes/events.

- Close any gaps between the top-down and bottom-up approaches.