This is not a NASA Website. You might learn something. It's YOUR space agency. Get involved. Take it back. Make it work - for YOU.
Russia

Russian Upper Stage Fires In The Wrong Direction and Splashes Its Payload

By Keith Cowing
NASA Watch
November 28, 2017
Russian Upper Stage Fires In The Wrong Direction and Splashes Its Payload

The reason for the unsuccessful launch of “Meteor-M” was called the human factor, Interfax (Google Translate)
“The reason for the Meteor-M satellite accident after launching from the Vostochny cosmodrome in the Amurskaya region could be the human factor, a source in the rocket and space industry told Interfax. “According to preliminary data, there was an error in the flight task of the carrier rocket and the Fregat booster block, as a result of which the first impulse was issued in the wrong orientation, so the upper stage together with the satellite entered the atmosphere and fell into the Atlantic Ocean “, the source said.”

NASA Watch founder, Explorers Club Fellow, ex-NASA, Away Teams, Journalist, Space & Astrobiology, Lapsed climber.

7 responses to “Russian Upper Stage Fires In The Wrong Direction and Splashes Its Payload”

  1. Jeff2Space says:
    0
    0

    Oops, yet another Russian launch failure. This can’t be good for business.

  2. Tim Blaxland says:
    0
    0

    I’m curious how this sort of error would be detected – obviously they have QA processes, but what form do they take? Do they have simulators that simulate the full flight with the flight software+commands prior to them being loaded onto the flight hardware?

    • fcrary says:
      0
      0

      I don’t know what process they follow; the Russians aren’t exactly big on transparency. But Fregat is effectively a spacecraft (multiple maneuvers to deliver multiple satellites to different orbits), not just an upper stage.

      For spacecraft in general, I think everyone does some sort of checking and validation before uploading a command sequence. The Russians learned that the hard way. That’s how they lost the Soviet Phobos 1 mission was lost on route to Mars. The computer they used for checking and validation was offline, someone decided it would be ok to skip that, and they accidentally uplinked a command with a fatal typo.

      But the nature, fidelity and testing varies tremendously. Sometimes, there will be an exact copy of all the spacecraft electronics, sitting in a lab, and command sequences will be run through it. More often, that’s only done for critical events, rather than every minute of operations. Another common practice is to speed things up. If two maneuvers are actually going to be four hours apart, with no commanding in between, the simulation might include a 30 minute rather than a four hour pause.

      It’s also common to model the spacecraft dynamics, to see if the sequence allows for enough time to complete a turn (you wouldn’t want the command to fire the rocket while the spacecraft is still turning) or you aren’t accidentally violating flight rules (don’t scan the star tracker’s field of view across the Sun…) But that can easily be a check for safety and operability, not intent.

      For example, with Cassini, if someone was supposed to build a sequence to observe Saturn’s atmosphere around 60 deg. north latitude, and mistakenly build it with a minus sign, the simulations and checks wouldn’t catch that. The software would say the turn to the observation was fine, enough time was allowed, no flight rules were violated, and produce a simulated image of the observation. But it would be up to operator (or someone looking over his shoulder) to notice the instruments were pointed at the wrong hemisphere. (And, no, I don’t know of any occasion when this happened, but I know of a few cases that were avoided by having more than one pair of eyes looking at the simulation output.)

      It’s also quite possible that checks for navigation and attitude control/turns would be modeled by separate software, and how (or if) they are coupled is can be done in different ways. It’s possible the navigation software simply produces the burn attitude and is just used as input for the command development process. (I.e. not the simulations aren’t run in closed loop.)

      By the way, it isn’t clear this is really operator error. That’s what Interfax reported yesterday. But a few hours ago, TASS said the manufacturer is now reinspecting guidance systems on other Fregat-M’s they have on the ground.

      • Bill Keksz says:
        0
        0

        “Separate” is key. As in don’t let the FSW GNC guys write the simulation. And always check the sim output vs FSW output.

  3. Andy Turnage says:
    0
    0

    Well, it looks like some Russians are blaming the clergyman who gave the pre-launch blessing. Gotta love this quote from the Moscow Times:

    “The popular theologian Andrei Kurayev said on Tuesday that the archbishop who blessed the satellite before its launch should be held accountable for its fate.

    “It is very strange that the church seemingly offers services but is never held liable for the quality of these services,” he said in an interview with the Govorit Moskva radio station.”

  4. Dewey Vanderhoff says:
    0
    0

    As a Russian press spokesman might spin it. ” The Fregat engine firing went precisely as planned. The planet got in the way…”

  5. Daniel Woodard says:
    0
    0

    The first step is to examine the data, document the actual sequence of events, and attempt to reproduce it with the exising flight software. If this can be done, the problem can be identified and corrected. If not, it will be hard to prevent a recurrance.