 |
Search for New Modeling ProcessesNASA’s Goddard Space Flight Center has studied the implications of Operationally Responsive Space on flight software architecture as well as what development tools are needed for a rapid spacecraft development effort, says Jonathan Wilmot of Goddard’s Aerospace Technology, Software Systems. Specifically, the work looked at the impact of a so-called core flight software system architecture and the integrated development environment on Operationally Responsive Space. “To construct, test and fly a satellite in the timeframes requires software that is essentially reused and/or has a high degree of automated code generation and automated test. The [core flight software] architecture is designed for component reuse and supports automatic configuration and code generation at the component level via the [integrated development environment],” he says. “The message of the paper was to show the applicability of the [core flight software] architecture to the goals of the initiative.”
The existing software modeling process might not be suitable given stringent Operationally Responsive Space requirements, says Wilmot. “The existing flight software system modeling process would need to be enhanced to support the [Operationally Responsive Space] needs for rapid code configuration, generation and test,” he says. “… A flight software architecture would need to support the modeling environment. A benefit of a component architecture is that a model for each component can also be included in the component library. When the spacecraft is being developed, the model for the component can be automatically extracted from the library and included in the overall system model,” he says.
Goddard is working with personnel at U.S. Air Force Research Laboratory to integrate core flight software and plug-and-play software modules with SpaceWire network interconnects, an Ethernet-friendly standard intended to help replace existing shared bus architectures aboard satellites with on-board switched networks and the use of standard protocols such as Internet Protocol (IP). It furthers the cause of Web-enabled space operations, among other things. The extensive use of Web-based tools was one of the groundbreaking dimensions of the TacSat-2 deployment, including one which enabled access to historical telemetry data.
Internet-Enabled Satellite OperationsThe TacSat-2 mission was designed to demonstrate, among other things, the tactical advantages of Operationally Responsive Space platforms including theater-specific orbits and elements that stressed user-friendliness and IP-based operate-from-anywhere capability. On the ground, tapping into the existing Modular Interoperable Service Terminal was another objective because these terminals are deployed as the primary means for conducting unmanned aerial vehicle operations.
As part of the mission, GeneSat-1, a NASA-funded project, opened a new chapter in Internet-enabled satellite operations in addition to its novel distributed command and data handling capabilities. It was one of several picosatellites which flew with the TacSat-2 mission. A team from Santa Clara University in California was responsible for all GeneSat-1 mission operations and the ground command and control network, says Chris Kitts, an associate professor of mechanical engineering and director of the Center for Robotic Exploration and Space Technologies, a multi-institution consortium or academic institutions at the NASA Ames Research Park. Genesat-1 was designed to conduct biological examinations to look for genetic changes in bacteria during spaceflight as part of a way to better understand the biological effects of the spaceflight environment and the impact on long-duration crewed space missions and space tourism. “The Genesat-1 network was all Internet based, extremely flexible and easily and quickly reconfigured for multiple users,” says Kitts. “It allowed for very inexpensive and operate-from-anywhere use while still being secure.”
Prior to GeneSat-1, the Santa Clara team performed the first live plug-and-play rapid integration and test demonstration in 2006. This was funded via the Air Force Research Laboratory’s university nanosatellite program. “We plugged in a component that we had never seen before our avionics backbone and had it integrated and in use within a few minutes,” says Kitts. “We were also able to arbitrarily cross-strap components from two different satellites that had been independently developed using our avionics specification. Our real objective is to develop what we call ‘composable missions’ where you not only plug in your satellite components, but you literally plug in your entire algorithm set. We have demonstrated aspects of this already with GeneSat-1, Sapphire and other robotic missions in which generic algorithms to handle health management are plugged into mission-specific models in order to detect, diagnose and resolve anomalies. We are actively researching extensions to this work to develop algorithms for command planning and payload processing.”
This is why all eyes are on the software. Risk reduction and integration are not easy to accomplish, so it helps to get it right the first time, line by line. And the demands of Operationally Responsive Space do not help matters, since the effort is all about responsiveness with an emphasis on speed. That requires faster processing, and more automation. Add it all up and you can see that this is not an easy undertaking by any means.
|
|
ALSO IN THIS EDITION
RECOMMENDED STORIES
SATELLITE TRANSPONDER GUIDE
Click here to get $100 off the cover price when you enter promo code DK6503 during checkout.
The Satellite Transponder Guide is your one-stop resource for information on North American transponders.
|
|
Email
Comments
Print
Reuse