FUNCTIONAL MODEL FOR SPACECRAFT OPERATIONS

Dave Welch* and Jay Karlin**

* AlliedSignal Technical Services Corporation, 7515 Mission Drive,
Lanham, MD 20706, USA. Fax: (301) 805-3130.
E-mail: WelchD@thorin.atsc.allied.com

**Viable Systems Incorporated, 12236 Stoney Bottom Road,
Germantown, MD 20874, USA. Fax: (301) 515-9637.
E-mail: Jay.J.Karlin@gsfc.nasa.gov

ABSTRACT. In the past, space projects have used developmental work breakdown structures based on traditional mission support organizational structures. Inconsistencies among the structures within each area make it difficult to transition functionality from one development area to another, either between ground components or from the ground system to the flight system. A functional breakdown of spacecraft mission operations is needed as a starting point for use in operational concept development. Such a breakdown enables the identification of what is needed in each component under alternative allocations of functions across a mission operations system. This assures that all mission support requirements are met by all the options considered when performing trade studies.

The largest hurdle to overcome in creating such a functional breakdown is getting beyond a development bias which tends to retain traditional functional allocations. The organizational focus of 'who' and 'where' needs to be separated from the functional focus of 'how', or the mission concept can be distorted. IDEF (Integrated Computer-Aided Manufacturing (ICAM) DEFinition), particularly IDEF0, produces structured representations of the functions in a system and of the information and objects which interrelate those functions. Using IDEF0 resulted in a model of 'pure' functions for use during early mission concept development. This model can be used to assign functional requirements to elements within various organizations in a way that allows better understanding of the full capability required of each.

INTRODUCTION

Current barriers to designing for operability start with a lack of thorough understanding by early mission designers as to what this practice entails. Often, the role of the operator is only vaguely understood. Their role in the overall mission system has often been overlooked in the past. With the advent of automation technologies, the operator's role must be understood at the very beginning of the system design, in order that it be properly replicated. Therefore, this understanding is necessary to take advantage of the cost reduction opportunities which can be achieved by fully integrating the mission system, that being all of the space and ground based software, hardware and people.

Functional modeling can help to provide this understanding. The major benefit of functional modeling is that it enables cost effective mission operations. It does this by helping to establish a clear understanding and consensus between parties of 'what' to do and 'how' to do it before attempting to decide 'where' to do it and by 'whom'. By developing 'pure' functional representations independent of any pre-existing assumptions as to physical organization, the flexibility of design concepts can be increased with much less risk of things "falling through the cracks". This is because everyone has a increased awareness of what it means to move functions between ground system components or from a ground system platform to a space system platform. Also, the role of the human in the loop is better understood when a decision is made to automate functions and reduce operations staffing.

By using such a model, mission trades between space, ground and operations can now be done in a way that allows for a true comparison between performing functions in these various environments. These provide the basis for end-to-end mission life cycle cost estimates which can be realistically viewed by all of the contributors to a mission's development. This will now allow a new user or owner of a system to have the ability to gauge and compare various systems and implementations and will provide a better understanding of the 'cost of performance'.

This model, however, only provides one perspective of the mission operations system. It is not a one size fits all view of the system, only a perspective which has been missing in the past. This perspective then becomes part of a larger framework which is discussed in the accompanying symposium paper entitled "A Framework of Mission Operations System Models" and it also becomes a very important component in the development of future cost modeling methodologies.

DEVELOPING THE MODEL USING IDEF0

The task of creating the model began when it was identified that there was a need for a framework to start mission system development which considered operations from the beginning. Likewise, there also existed a need to describe existing mission system applications to a new user in order to gain the benefit of re-use. Finally, an understanding of the role of the operator was necessary in order to design and develop autonomous systems. For these reasons, a major goal of the model has been to isolate the operations requiring experts from those which are routine. Therefore we tended to concentrate on the functions which concern the health and safety monitoring and control of the spacecraft and attempted to separate the routine functions of sequencing, control and data transfer from the expert functions of planning and analysis. By segregating the functions in this manner, the routine functions are isolated so that they can be performed either on-board the spacecraft or on the ground.

The satellite mission operations functional model was developed using IDEF. IDEF is a US Federal Information Processing Standard (FIPS) which captures the true complexity of a process and allows constraints, resources and iterations to be considered as an integral part of the process. IDEF allows the process to be decomposed into sets of connected activities. IDEF also forced a view which is independent of where or how any particular function is performed. Finally, IDEF enables the use of Activity Based Costing. See figure 1 for an overview of the IDEF nomenclature.


Figure 1 - IDEF Nomenclature

The information fed into the modeling process was gathered from experienced mission operations engineers. Although the engineers understood operations fully, they lacked a way of summarizing functions concisely and comprehensively without long narration. Over the course of the model construction, as a result of interaction with the modeler in the IDEF environment, the engineers developed a procedure free viewpoint, not to mention a highly useful tool for use in eventual automation.

This work has since also transitioned into a task to develop guidelines for early operations concept work. Because of this effort, the model also has been developed to complement the 13 Mission Operations System Functions which have been defined by G. Squibb of NASA's Jet Propulsion Laboratory and described in "Cost Effective Space Mission Operations".

FUNCTIONAL MODEL DESCRIPTION

The current version of the model was primarily created as a template for use in beginning the development of a mission operations concept. Designed to help new projects determine and understand what needs to be done at the offset, it allows for a comparison between functions performed in various environments. Also, since it was developed with an attempt at neutrality between space and ground functions, it is also hoped that it will provide a means for cataloguing existing re-usable system capabilities regardless of where they reside.

Accomplish Mission

The highest level function in the model is accomplish mission (see figure 2). In performing this function, the mission objectives and the mission management set the goals and boundaries and thus constrain and guide the function. Expertise is the input which is used to create the desired output, which is useful information. During the life of the mission, resources will be the mechanism's necessary to perform the mission.


Figure 2 - Mission Operations Model Top-level View

The top level functions to accomplish the mission are plan mission, operate the mission system and utilize the mission information (see figure 3). Expertise is the input into the planning function, along with updates of mission status from the data utilization function during the testing and in-flight phases. The output of the planning function (A1) includes procedures and validated database information as well as specific inputs and requests. The mechanism's for accomplishing this function include development and maintenance support, system engineering support and integration and test support. The procedures then work to constrain the operate mission system function (A2) which takes the planning inputs in order to gather the desired mission information for use by the utilize data function. Mechanism's supporting the operate mission system function are the validated mission database, computer and communication support, maintenance and, during the testing and early checkout phase, integration and test support. The other output of the operate function are unresolved problems which are sent back to the planning experts. The utilize function (A3), then takes the mission information and converts it into useful findings and reports current status back to planning to gauge the current success in meeting the mission objectives.


Figure 3 - Accomplish Mission

Plan Mission

The planning function (A1) consists of three major sub-functions, the operations design (including redesign), the development, modification and maintenance of procedures and databases and the planning of what is desired of the rest of the system to support both testing and in-flight operations (see figure 4). Functionally, there is no difference in the planning activities which take place at the very beginning of a mission and those which occur after a budget cut once the prime mission goals have been accomplished. Yet it seems that these processes are often handled by different groups as the spacecraft passes through it's design, development, test and in-flight phases, each often using their own separate tool suites and methodologies and with little informational flow from one phase to the next.


Figure 4 - Plan Mission

The operations design (A11) is an ongoing process which spans the entire life of the mission. Activities include developing operations concepts ands plans which complement the mission objectives and helps describe the system functional requirements and architecture, providing cost and schedule estimates. This work includes tasks such as conceptualizing the needs and objectives for the mission and developing options for meeting these objectives, assisting in the performance of system and subsystem trade studies and feasibility assessments, development and modification of launch and early orbit operations and checkout and contingency plans as well as nominal in-flight plans, making adjustments based on reviews or change requests, and in-flight modification of mission objectives or requirements in response to unforeseen events such as a spacecraft malfunction or a budget cut.

The development of procedures and the database population activities (A12) generally begins during the development phase and maintenance continues until the end of the mission. These include development and maintenance of procedures based on the mission operations plans and also any additional plans developed to support mission system testing. This function also includes such things as creating displays, scripts, and voice and facility assignments.

Planning to operate (A13) the spacecraft and ground systems involves providing necessary information to meet the mission objectives by supporting navigation, the spacecraft bus and the payload. These activities include requesting modifications to systems and/or procedures in response to changing satellite capabilities, failures or returned data and responding to unforeseen events in order to assure that mission objectives are met and will continue to be met.

The three primary areas of plan to operate are navigation, spacecraft bus operations and science or payload operation. These planning functions include such items as pointing and trajectory control, flight software utilization management, predicted ephemeris access, resource utilization predictions, spacecraft state and trend predictions, science observation planning and fault resolution planning.

Operate Mission System

The operate mission system function (A2) consists of four major sub-functions, scheduling mission activities, performing the mission activities, evaluating the activity performance as well as the general health and safety of the mission system and transporting and handling mission data (see figure 5). This set of functions make up the routine operations, which are candidates for automation.


Figure 5 - Operate Mission System

Scheduling activities (A21) is a function which has historically resulted in the generation of an activity timeline which is then formatted into a spacecraft command load and an integrated timeline printout. Inputs to support this function have historically been planning aids (ground track data) from navigation, network schedule and status from the lead network, planning inputs from the investigators, spacecraft engineers and navigation (orbit and/or attitude adjustments) and mission guidance from mission planning. From a purely functional perspective, inputs would include spacecraft ephemeris from navigation, network schedule and status from data transfer, planning inputs from payload, spacecraft and navigation and planning guidance from mission planning (primarily approval for modifications to the overall mission operations plan). The scheduling function is constrained by the operating procedures and have to react to any current alarm or alert indications. Outputs of the scheduling function are activity requests for the system to perform, information on confirmed resource utilization and problems which cannot be resolved simply by scheduling or requesting an activity be performed.

The scheduling activities in turn consist of three sub-functions, generating events, allocating resources and sequencing activities (see figure 6). Generating events (A211) consists of using predicted ephemeris data in order to determine ground and space network view periods as well as the timing of events which are predicted to occur as a result of the spacecraft moving through it's environment. These events consist of such things as day-night transition times and targets of opportunity and are pre-defined and contained within the procedures which were generated earlier. Allocating resources (A212) is done to ensure that the mission goals are met and include resources such as network and communication resources which are shared with other missions as well as ground data systems which may be shared between multiple missions or which may be used by a dedicated mission, but for various tasks which have to be managed, personnel which are needed to support the system and the spacecraft resources themselves which may be shared amongst different science teams. Finally, sequence (ground and space) activities (A213) handles planning inputs, provides event driven activity requests and responds to alarms with predetermined activity requests and checks for activity conflicts. It's outputs include activity requests and unresolved problems which are sent back to the planning experts. These problems include unresolved constraint violations and alarms that are received, but which do not have a pre-defined response activity.


Figure 6 - Schedule Activities

Going back up a level again, we come to perform activities (see figure 5). The perform activities (A22) function has historically resulted in directing the real-time operations of the spacecraft, in accordance with an activity timeline and with responsibilities that include assuring reception of required data on the ground, command and control of the spacecraft and maintaining the health and safety of the satellite. Inputs to support this function have historically been activity and event timelines and network schedules from the command management system and the mission planner, spacecraft telemetry and ground network status information. Other inputs may have included requests for real-time adjustments from the investigators, spacecraft engineers or orbit/attitude control elements. From a purely functional perspective, inputs include sequences derived by sequence development and adjustments prescribed from the monitoring of the health and safety of the spacecraft in real-time or from the planning and analysis entities. The output of this function is information from the mission system.

The Evaluate Activities and Background (A23) function consists of two major activities, monitoring the system background information for health and safety status and monitoring the performance of the system operation and data transfer and exchange (see figure 7). This function compares the mission system information to the planned and expected status to provide an evaluation of the system performance. It also issues alarms or alerts when an unexpected or undesired status is detected. The monitor background function (A231) consists of such activities as limit and state checking. This function only monitors that the system operates within prescribed boundaries and issues alarms. The monitor performance function (A232) on the other hand, makes sure that the system is operating according to the plan (see figure 8). Historically, this has been the primary function of the flight operations personnel. This function verifies command level execution (step by step), verifies the activity (or plan) level execution by comparing the present status against the planned status, including any environmental effects and provides data accounting, both quantity and quality by ensuring that all scheduled data is captured or accounted for and checks the data for transmission errors which can impact quality.


Figure 7 - Evaluate Activities and Background


Figure 8 - Monitor Performance

The transport and deliver data (A24) function provides a service by which the other functions can pass information back and forth. This may include exchange of information between two functions on-board the spacecraft, exchange of data between one space vehicle and another or between a spacecraft and the ground, or transfer of information between ground elements. Coordination of operational activities relating to space to ground contacts is generally provided by advance scheduling of resources and real-time voice communications.

Utilize Mission Data

The utilize mission data function (A3) primarily consists of the study of data, including higher level processing and evaluation, and breaks down into the same three primary areas as the plan to operate function. These are navigation, spacecraft bus operations and science or payload operation. For navigation, these analysis functions include such items as tracking data processing, definitive ephemeris generation, definitive attitude generation, management of expendables and presentations and papers describing orbit and/or attitude findings. For spacecraft bus operations, these analysis functions include on-board recorder management, power analysis, flight software management, anomaly investigation, trending and presentations and papers on engineering findings. The science or payload analysis includes science data processing, analysis of quicklook products, data archive, and presentations and papers discussing the scientific findings.

CONCLUSIONS

In order to provide cost effective mission operations in the future, we must break the development paradigm which tends to retain traditional functional allocations, enable a system viewpoint to see new ways to do things and examine mission functions, identifying the critical parameters prior to developing an architecture. By using a functional breakdown to perform early concept and design work and to perform mission trade studies, we can view alternative allocations of functions across a mission operations system with an added assurance that the trade options will meet the mission requirements and come away with a better understanding of the "cost of performance". The will allow the customer of the future to better gauge a particular systems capabilities and to better compare systems with similar functionality.

REFERENCES

Larson, W. and Boden, D. Cost Effective Space Mission Operations. McGraw Hill, April 1996.

Mayer, R. J., Painter, M. K. and deWitte, P. S. IDEF Family of Methods for Concurrent Engineering and Business Re-engineering Applications. Knowledge Based Systems, Inc., 1994.

FIPS PUB 183. Integration Definition for Function Modeling (IDEF0). National Institute for Standards and Technology, December 21, 1993.

Karlin, J. and Welch, D. A Framework of Mission Operations System Models. Proceedings of the Fourth International Symposium on Ground Data Systems for Space Mission Operations (SpaceOps 96), September 1996.