INTRODUCTION Spacecrafts are comprised of numerous complex systems. This includes the equipment that makeup the spacecraft used for delivery, and the various payloads and science instruments used to meet the research objectives. Accompanying this complexity will be the assorted complications. As individual components do not always operate as projected, some failures are to be expected. This is further compounded as the system's complexity increases. With payload costs just recently starting to approach $1000 per pound (a tenth of that experienced by the space shuttle) ( SpaceX, 2011), designers must still strike a balance between system redundancy, sensor allocation and hardware weight. An absence of redundancy minimizes the options an operator has should a failure occur. A lack of instrumentation limits visibility into system performance. For many systems, timely recognition of an anomalous situation means the issue gets evaluated and a course of action is decided on quickly. Taking corrective action sooner can help minimize damage generated from off-nominal conditions, or avoid serious outcomes for those problems that can escalate rapidly. The ability to quickly detect and identify anomalies that arise is vital for critical space operations. Anomaly Detection The predominant method for developing an anomaly detection system is to select one or more applications that may fit one's needs. The selection process may be limited to what is readily available, and a scrub against the system requirements may end up diminished. After these modules are selected, development then starts on a system-level architecture that can integrate the various elements into the current design. As this is a niche application, a certain amount of tailoring will be required to render the forthcoming architecture functional. An application that is not a good fit can amass excessive development hours in an effort to make the system operational. Detecting an anomaly is the first half of providing the operator with the vital data necessary to develop a course of action. After an anomaly has been detected, the other half of the process (and equally important) is to isolate the fault within the system. Isolation to a component or subassembly provides the domain experts with the essential information necessary to respond and possibly remedy the situation. Fault isolation will optimally be able to point to a specific source. However, a lack of sensor information often leads to uncertainty which can result in an inadequate diagnosis. It is often the case that the initial data related to the anomaly is not sufficient to pinpoint the original problem, and involve additional troubleshooting to find the cause. This may result in an initial isolation of the problem to an upper subsystem level. In this limited-visibility scenario, it would not be unusual to have multiple suspect subassemblies and/or components identified. In addition to issues related to limited sensor data, system complexity can make the fault isolation process arduous. The task of isolating to a fault entails assessing all possible contributors to the problem, each with varying degrees of sensor coverage. For a complex system, these contributors can number into the hundreds and possibly thousands. A Modeling Space Operations Systems Using SysML as to Enable Anomaly Detection Luis Rabelo University of Central Florida Tom Clark ERC Inc. ABSTRACT Although a multitude of anomaly detection and fault isolation programs can be found in the research, there does not appear to be any work published on architectural templates that could take advantage of multiple programs and integrate them into the desired systems. More specifically, there is an absence of a methodological process for generating anomaly detection and fault isolation designs to either embed within new system concepts, or supplement existing schemes. This paper introduces a new approach based on systems engineering and the System Modeli