Abstract-Small spacecraft are more highly resource-constrained by mass, power, volume, delivery timelines, and financial cost relative to their larger counterparts. Small spacecraft are operationally challenging because subsystem functions are coupled and constrained by the limited available commodities (e.g. data, energy, and access times to ground resources). Furthermore, additional operational complexities arise because small spacecraft components are physically integrated, which may yield thermal or radio frequency interference.In this paper, we extend our initial Model Based Systems Engineering (MBSE) framework developed for a small spacecraft mission by demonstrating the ability to model different behaviors and scenarios.We integrate several simulation tools to execute SysML-based behavior models, including subsystem functions and internal states of the spacecraft. We demonstrate utility of this approach to drive the system analysis and design process. We demonstrate applicability of the simulation environment to capture realistic spacecraft operational scenarios, which include energy collection, the data acquisition, and downloading to ground stations.The integrated modeling environment enables users to extract feasibility, performance, and robustness metrics. This enables visualization of both the physical states (e.g. position, attitude) and functional states (e.g. operating points of various subsystems) of the spacecraft for representative mission scenarios.The modeling approach presented in this paper offers spacecraft designers and operators the opportunity to assess the feasibility of vehicle and network parameters, as well as the feasibility of operational schedules. This will enable future missions to benefit from using these models throughout the full design, test, and fly cycle. In particular, vehicle and network parameters and schedules can be verified prior to being implemented, during mission operations, and can also be updated in near real-time with operational performance feedback.

No abstract

, the Cassini-Huygens Mission sent the largest interplanetary spacecraft ever built in'the service of science. Carrying a spite of 12 scientific instruments and an atmospheric entry I probe, this complex spacecraft to.'expldre the Saturn system may not have gotten off the ground without uhdergbing significant design changes and qost reductions. ;As a means to control operations cost, a no

One of the most challenging tasks in a space science mission is designing the Mission Operations System (MOS). Whereas the focus of the project is getting the spacecraft built and tested for launch, the mission operations engineers must build a system to carry out the science objectives. The completed MOS design is then formally assessed in the many reviews. Once a mission has completed the reviews, the Mission Operation System (MOS) design has been validated to the Functional Requirements and is ready for operations. The design was built based on heritage processes, new technology, and lessons learned from past experience. Furthermore, our operational concepts must be properly mapped to the mission design and science objectives. However, during the course of implementing the science objective in the operations phase after launch, the MOS experiences an evolutional change to adapt for actual performance characteristics. This drives the re-engineering of the MOS, because the MOS includes the flight and ground segments. Using the Spitzer mission as an example we demonstrate how the MOS design evolved for both the prime and extended mission to enhance the overall efficiency for science return. In our re-engineering process, we ensured that no requirements were violated or mission objectives compromised. In most cases, optimized performance across the MOS, including gains in science return as well as savings in the budget profile was achieved. Finally, we suggest a need to better categorize the Operations Phase (Phase E) in the NASA Life-Cycle Phases of Formulation and Implementation.

The Cassini-Huygens operations design, as described in a companion paper, relies on telecommunications and distributed computing to share operational responsibilities among JPL and instrument teams. From their home institutions, scientists are actively involved in planning, developing sequences, and commanding and monitoring the spacecraft. This paper proposes design guidelines, based on Cassini-Huygens experience, for future ground systems that face similar challenges of spatial decentralization and functional reallocation.In contrast to past deep space missions in which there was simply data exchange between JPL and scientists, the Cassini-Huygens environment has progressed into a complex of integrated systems. The lessons learned during this evolution include the following: (a) A logical architecture that can be overlaid on different physical implementations will reduce re-engineering for multiple environments. (b) Platform decisions should recognize the cost constraints of all potential users of project-supplied software. In a world accustomed to heterogeneous hardware, standardization on a single, expensive platform will create recurring conflict. (c) Separate systems will be bound by differing institutional restrictions, and upgrade patterns will differ according to institutional drivers and funding.The distributed operations paradigm has also accelerated the blurring of responsibilities between scientists and engineers. As the tools in the Cassini-Huygens ground system have evolved to support the dispersion of responsibilities such as spacecraft pointing and health & safety, these issues have been worked out: (d) Connectivity alone does not suffice. An electronic, up to date, widely accessible picture of the collective plan is required. (e) Allocation of functionality to tool must be managed at the project level to minimize redundancy. (f) Changes to the underlying constructs in the software architecture such as models and flight rules will apply to multiple tools in multiple systems. When the enhancements are introduced earlier in some places than in other places, substantial confusion can result from differing answers to the same question. The payoff for rapid introduction of improvements needs to be weighed against the penalty of discrepancies due to lack of synchronization. (g) Without specialist operators, tools need to be easier to use, have better documentation, and come with tech support. (h) When tools meet both engineering and science needs, contention for development resources intensifies. An arbitration process for prioritizing development tasks needs to be in place. (i) As in many modern systems with ongoing development, late interface changes due to asynchronous development of various systems are to be expected.