This week, the Miles Team Weekly Topic rotation once again revisits communication for the NASA Cube Quest Challenge.
The Japanese Space Agency successfully launched a satellite named Hitomi or ASTRO-H on February 17, 2016 to study the hard sources of x-ray radiation in the universe. The $286 million dollar satellite has only been in orbit for only a little over a month when, on March 26th, the anomalous event (or events) occurred that would lead to the satellite’s disintegration. JAXA report estimates that Hitomi (ASTRO-H) broke into 11 objects, 2 of which have since burned up in re-entry to Earth’s atmosphere. The official analysis indicates that the cause of disintegration was due to an error in the satellite’s attitude control system. Such a situation could arise from a bad software update, an unforeseen situation that was not programmed for, or a reaction/inaction resulting from environmental factors. Sadly, as this catastrophe demonstrates, software and process errors still remain major risks to space missions. They present a significant opportunity for Miles to overcome and to stand apart. That brings us to this week’s topic, the Hitomi (ASTRO-H) satellite and why software can make or break a satellite.
Since room and weight allowance inside of satellites are extremely limited due to launch vehicles and budgets, every component must work as intended for the duration of the mission. These parts must work in harmony with other components, to make up correctly functioning systems and handle any unforeseen circumstances. Software is the glue that connects and directs all of these components and systems in order to perform in the correct manner and time according to the mission. Ground to satellite communications can mitigate risk of component or software failure when the satellite is within an open window of clear contact with the command station on the ground. Despite careful planning and the ability to update software from Earth, lack of ground contact, errors in software, and possibly even the radiation environment near the South Atlantic created the right conditions for the attitude control system of Hitomi to malfunction and to destroy the satellite.
Hitomi’s (ASTRO-H) attitude control system, which was intended to keep the satellite’s solar panels oriented toward the sun as it moved to point its sensor array at the galaxy Markarian 205, seems to have corrected for a rotation that was not happening due to an error in the communications between the inertia sensor system and the star tracking system. This correction ended up speeding up the actual rate of rotation to beyond the design parameters and resulted in the disintegration of the spacecraft. In contrast, the Miles satellite will be going much farther, to lunar orbit, which poses a higher risk for software failure. We have opted to take a more autonomous approach to eliminate the risks of faulty software updates, human error in analyzing sensor signals, and issuing corrective commands. Team member Seth Dennis, interviewed one of the software team experts on Team Miles to gain insight into the software design process.
Seth: “Sydnie, would you share your thoughts on how Team Miles is approaching the programming challenge to ensure a successful, autonomously operating satellite?”
Sydnie: ”Teamwork is essential to our approach. There are some key principles for group software development that we believe will help us develop a robust and stable on-board system. The group is in frequent communication. We not only have regularly scheduled team meetings but we use chat and other types of online collaboration software for more immediate issues. Everyone is writing their code using the same versions of the operating system, language, and hardware that will be loaded onto the spacecraft. A well-planned software architecture is crucial, where individual modules can be developed separately and brought together at well documented integration points. By addressing these points, we are as prepared as possible for any surprises that will arise during the mission.”
Seth: “Thank you, Sydnie. Another question I have is in regards to how Team Miles is planning to ensure a safe software operating system that accounts for all challenges and situations to ensure the Miles satellite can safely, successfully, and autonomously, orbit the Moon?”
Sydnie: “Since we are developing an autonomous system, we need to implement different testing methodologies than if we were developing a manned system. The thing that’s unique to an autonomous system is that the system will be making decisions during the mission without our input. To test that, we need to be able to simulate situations that the spacecraft might encounter and ensure that we’ve correctly implemented the algorithms that are meant to form the basis of the “decisions.” That means simulating both the expected and unexpected “surprises.” It’s going to be challenging and I imagine that we’ll learn a lot during this process!”
Seth: “Thank you, Sydnie. Computer simulation will definitely be key to discover all those tricky situations to rigorously test our code. We did it with our flight plan, we can do it with our satellite’s operating parameters!”
That is all for this week on communications! Please follow us on Twitter @MilesSpace and check out the press release and analysis that the Japanese Space Agency presented on the possible causes of failure of the ASTRO-H Satellite: http://global.jaxa.jp/projects/sat/astro_h/files/topics_20160415.pdf