Fig. 14-1. The 13 Functions of Mission Operations System and How they Interact. Functions in the shaded area share data within the mission database. We briefly discuss them in Sec. 14.2. Functions 4, 8, and 9 are part of a broader category called data services.

Figure 14-1 overviews a mission operations system that carries out the mission operations concept. This system processes information and controls the ground and space assets so users and operators get needed information and services. Most missions today focus on providing information to users or customers—the downlink. But control drives much of the cost and complexity of operations—the uplink. We will see this in the following sections.

There is a fundamental difference in mindset between designers and operators of space systems. Designers expect things to work; operators expect things to go wrong! Both perspectives are necessary. Mission operators usually help develop the mission concept, but they often get involved too late—long after the initial design phase in which teams can make cost-effective choices. Operators should get involved early enough to influence planning and design, so they can reduce the life-cycle costs of space missions. They help develop flight rales, which govern operators' responses to anomalies and ensure timely responses consistent with mission success.

Figure 14-1 shows 13 mission operation functions. We can combine or eliminate some of them to reduce cost and complexity. Nine share data through the mission database and the space element's avionics and they require extensive data processing:

1. Mission planning—deciding what to do and when

2. Activity planning and development—creating operational scenarios and developing command loads

3. Mission control—managing daily activities

4. Data transport and delivery—establishing communication links and managing dataflow

5. Navigation and orbit control—determining where the spacecraft is and planning maneuvers

6. Spacecraft operations—managing the spacecraft bus

7. Payload operations—managing the spacecraft's payload g. Data processing—managing the data flow on the spacecraft and on the ground

9. Archiving and maintaining the mission database—managing all data generated by the mission

The order from upper left (mission planning) clockwise to lower left reflects the usual order in processing: analyzing uplinks, analyzing downlinks, and then planning new uplink activities. The other four functions provide support for all aspects of mission operations:

10. Systems engineering, integration, and test—maintaining the mission operations concept

11. Computers and communications support—planning for and maintaining the infrastructure

12. Developing and maintaining software—spread throughout all functions

13. Managing mission operations—maintaining the big-picture perspective, managing interfaces, and budget

A big question is, "How many people must we have to do mission operations?" The obvious answer is, "It depends." It depends on the organization's operational requirements and constraints, as well as the number and complexity of functions, complexity of the mission design, complexity of flight and ground systems, and how much risk the operations organization will take.

The number of operations people required can vary significantly between military, commercial, and scientific spacecraft and can vary significantly between individual missions within each category. The cost difference between a 5 person operations team and a 50 person operations team is 6 to 7 million dollars per year. This chapter will try and identify how differences in payload and spacecraft design, space environment, ground systems, the ops organization design, and risk policies can influence operations costs.

Section 14.1 describes a process for operations design and development. We emphasize the importance of defining an early operations concept to clarify requirements on the operations system. Armed with these requirements, we can meet goals for operations costs by negotiating with the other space mission elements to reduce their operational complexity, thus keeping costs acceptable across the full mission life cycle. Once we've iterated through die process, gotten costs within guidelines, and developed a workable mission operations concept and design, we can more effectively deal with the cost drivers for mission operations.

Section 14.2 defines mission operations in terms of 13 functions that are common across a wide variety of mission types and operations team sizes. Analyzing each function helps us understand recent trends in trying to reduce costs and in automation. Section 14.3 then discusses what determines the size and cost of space mission operations.

We're now converting functions that people have done into ones that hardware and software can do. We're also moving onto the spacecraft parts of operations functions traditionally done on the ground. Using software in place of people doesn't always save money but we need to assess this option. Section 14.4 provides some guidelines and insights about high payoffs from investments in operations technology and automation.

For a detailed discussion of the design of mission operations for scientific remote sensing missions, see Wall and Ledbetter [1991]. Because of the continuing pressure to contain cost, a number of authors has described methods for operations cost reductions on both individual missions [Bloch, 1994; Mandl et al., 1994; van der Ha, 1992] and various classes of missions [Cameron, Landshof, and Whitworth, 1994; Hughes, Shirah, and Luczak, 1994; Landshof, Harvey, and Marshall, 1994], Much of this cost reduction strategy has been summarized by Boden and Larson [199S] and Marshall, Landshof, and van der Ha [1996],

14.1 Developing a Mission Operations Plan

For unmanned space missions the Mission Operations Plan (MOP) describes in operators' and users' terms the operational attributes of the flight and ground-based elements. The plan usually results from the cooperative work of several disciplines. Its development is similar to that of a space mission concept but the MOP is more detailed and emphasizes the way we operate the mission and use the flight vehicle (operational characteristics), crew, and ground operations team. It is generated in phases and becomes more detailed as our mission design progresses.

The MOP follows from, and must be consistent with, the mission concept It is one of the most important deliverables from the mission operations organization before launch. A good MOP helps assure that the operations organization provides a tested and certified mission operations system that meets requirements at the lowest cost The operations organization and management also use the MOP as their main tool to influence the design and operability of the mission and spacecraft. Its iterative development often changes the mission concept flight vehicle, and software, both flight and ground. By combining the operations concept with assessments of operational complexity, we can determine the probable costs of operations early in the mission design. Table 14-1 outlines the steps needed to develop a useful MOP.

Step 1. Identify the Mission Concept, Supporting Architecture, and Key Performance Requirements

We begin developing the MOP by examining the mission concept and supporting architecture. By obtaining the information listed below, we can describe the mission in language that users and operators understand. Sometimes information isn't available. Sometimes, the operations design isn't very far along or isn't specified in the mission architecture. In these cases, we make assumptions and document them in the MOP. Of course, we update the MOP as the assumptions change or more data becomes available. We can then determine the cost of changes by modifying the operations concept and re-evaluating the cost and complexity of the mission operations.

Mission objectives identify what the ground crew, spacecraft, and payload must do for mission success. They help us define and describe how people will use the payload data. We also need to know the timeliness requirements for payload-processed data and the mission's overall criteria for success, such as the amount of data to be returned.

TABLE 14-1. Developing a Mission Operations Plan. Many items are detailed by Boden and Larson [1995]. See text for a discussion of each step.


Key Items

1. Identify the mission concept, supporting architecture, and performance requirements (Chap.1)

• Mission scope, objectives, and payload requirements

• Mission philosophies, strategies, and tactics

• Characteristics of the end-to-end information system

• Identify performance requirements and constraints

2. Determine scope of functions needed for mission operations (Sec. 14.2)

• Identify functions necessary for different mission phase

• Functions usually vary for different mission concepts and architectures. Combine or eliminate if possible

3. Identify ways to accomplish functions and whether capability exists or must be developed (Sec. 14.2)

• Where functions are accomplished (space or ground)

• Space-based crew capabilities

• Degree of automation on the ground

• Degree of autonomy on spacecraft and for flight crew

• Software reuse (space and ground)

4. Do trades for items identified in the previous step.

• Try to define operational scenarios before selecting options. These trades occur within the operations element and include the flight software

5. Develop operational scenarios and flight techniques

• Operations scenarios and flight techniques are step-by-step activity descriptions. Identify key issues and drivers

• Develop scenarios and flight techniques for functions from step 2 and options selected in step 4

6. Develop timelines for each scenario

• Timelines identify events, their frequency, and which organization is responsible. They drive the characteristics for each operations function

7. Determine resources needed for each step of each scenario

• Allocating hardware, software, or people depends on what, how quickly, and how long functions must be done

8. Develop data-flow diagrams (Sec 2.1.1)

• Data-flow diagrams drive the data systems and the command, control, and communications architecture

9. Characterize responsibilities of each team

• Identify organizations involved and their structure, responsibility, interfaces, and size. To be cost-effective, minimize the number of organizations and interfaces

• Develop training plan for ground team and flight crew

10. Assess mission utility, complexity, and operations cost driver

• Refine development and operations costs each time you update the Mission Operations Plan

11. Identify derived requirements

• Identify derived requirements and ensure consistency with top-level requirements

• Identify cost and complexity drivers

• Negotiate changes to mission concept and architecture

12. Generate technology development plan

• If the technology to support mission operations doesn't exist, generate a plan to develop it

13. Iterate and document

• iteration may occur at each step

• Document decisions and their reasons

The mission description tells us the trajectory, launch dates and windows, trajectory profile, maneuver profile needed to meet mission objectives, mission phases, and the activities required during each phase. Observation strategies describe how we'll collect the mission data. We define and finalize the observation strategies and mission description before launch or adapt them to data gathered during the mission.

Sometimes, the operations organization develops the operating philosophies, strategies, and tactics. They may relate to the mission objectives or simply derive from the designer's background or experience. We must determine whether the philosophies, strategies, and tactics are mandatory, highly desirable, or just personal or organizational preference. Examples include

• Maximize real-time contact and commanding versus onboard autonomy and data-storage

• Maximize the involvement of educational institutions and teach students key aspects of issues like operations or space physics

• Make sure a central authority approves all commands

• Limit the image budget to 50,000 images

• Deploy a communications satellite early in the mission

The mission sponsor and the project manager may impose nontechnical constraints. Operators usually follow these constraints until the project manager learns they increase the mission's cost or make operations unacceptable or unsafe. Examples of program constraints include

• Limit mission cost and cost profiles

• Use a specific tracking network (for example, TDRS)

• Use existing flight hardware

• Use existing ground systems and design the spacecraft to be compatible with them

• Centralize or distribute operational teams

• Use multi-mission versus project-dedicated teams

• Involve educators and the academic community, including students

We must identify capabilities and characteristics of the end-to-end information system early on so we clearly understand the mission's information needs. These requirements at the system level include

• Using information standards

• Locating capabilities and processes (includes both space and ground)

• Characterizing inputs and outputs for the information systems

We must state the information systems requirements in terms that operators and users can understand, not in jargon used by computer scientists and programmers.

As discussed in Chap. 15, most missions are designed around a specific agency's ground system, such as the Air Force's Satellite Control Network, NASA's Satellite Tracking and Data Network (STDN), or the European Space Operations Center. Each ground system has standard services that support the mission at lower cost if the mission meets specified interfaces and standards. We follow these requirements on the flight system until they hinder our ability to meet mission objectives.

This first step is key to the overall success and cost of mission operations. Here we gain insight about what to do and why. We begin determining performance requirements and constraints that will drastically affect the mission's cost and complexity. If we get the requirements wrong, we get the system wrong.

Step 2. Determine Scope of Functions Needed for Mission Operations

Before deciding how functions must be done, we usually divide the mission into discrete, workable phases such as launch, early orbit, normal operations, entry, descent, and landing. These phases usually have distinct goals and objectives, so their operational requirements are different. The mission concept drives top-level functions, but abilities of the crew, spacecraft, and payload determine the detailed functions we must carry out A completely autonomous payload requires few crew operations, whereas a spacecraft payload that can't compute or store enough data onboard may require more control or automation on the ground. Thus, to determine what we must do, we have to understand characteristics of the spacecraft bus and payload. Characteristics essential to the mission concept may become clear early in the conceptual design phase. Or we may develop them as part of the Mission Operations Plan. Through iterative discussions, the operators and developers define the characteristics described below.

Users often ask operators to support a wide variety and number of pay loads during a mission. Including payload designers and mission planners while developing the mission concept leads to timely definition of the payload characteristics. For a multiple-payload mission, we must understand early how each payload's constraints interact with the operations of other payloads and the ground system.

To understand how a payload operates, we must describe what the payload does during an operational period by asking

• What are the payload attributes?

• What is the commanding philosophy—buffer use, micro-commands, tables?

• Does the payload use default values? Can ground operators change them?

• Can some commands damage the payload or endanger the spacecraft?

• Do some operations depend on previous commands?

• Does the payload use position commands or incremental commands to control rotating or stepping mechanisms?

• What command classes does the payload use—real-time, stored, 2-stage?

• What processing occurs within the instrument?

• How can we describe the payload in terms of

- CPU/memory, closed-loop functions, and predictive commanding vs. event-driven commanding?

- Instruments the space element must control?

- Mechanical power and thermal attributes?

- Avoidance areas (Sun, Earth, South Atlantic Anomaly, Venus, or Moon)?

- Requirements for controlling the space element?

- Safety constraints?

• Do the payload apertures drive the space vehicle's pointing control?

• What are the user-specified parameters for operation?

• How do these parameters convert into payload commands?

• What is the payload heritage?

• What ground processing and analysis do we need to support its operation?

The example below shows how planning payload operations helps us define the mission concept It also shows how operational workarounds support mission success.

An instrument's aperture had a field of view of ten arc-sec. The spacecraft had pointing capability of 20 arc-sec. In this case, the operators could never be sure the object was in the instrument's field of view. The solution was to:

• Command the spacecraft to the desired position

• Observe with a different instrument having a wider field of view to see how far the spacecraft was off the desired position

• Generate attitude commands to move the spacecraft slightly (tweak commands) until the actual attitude corresponded to the desired attitude

• Verify the attitude errors were gone

• Select the instrument with the narrow aperture and observe as specified

This single design error caused real-time operations, such as decision making and commanding, to become nonroutine for this mission—a big cost driver. These operations required more ground software, controllers trained in commanding the attitude-control system, and more people whenever they used the instrument The goal of generating a MOP is to identify early any incompatibilities and cost drivers like this one—before we design and build any hardware.

It's a good idea to ask the designer of a payload instrument how to go from an observer requirement to a set of commands for the instrument Sometimes, the answer is simple, but it could be complex if instruments have been designed for a laboratory rather than for space operation.

As is true for the payload's capabilities and characteristics, timely definition of the spacecraft's characteristics depends on including spacecraft designers and mission planners in developing die mission concept People working on the concept have to answer the following types of questions for the overall spacecraft and its subsystems:

• What are the spacecraft's operational attributes?

• How are the values of these commands determined?

• How many commandable states are required?

• Are engineering calibrations required? What are the purpose, frequency, and schedule constraints of the calibrations?

• How many engineering channels need monitoring?

• Do these channels provide subsystem-level information to the operators, or must operators derive information about subsystems?

• Are guide stars used? If so, how are they selected?

• How does the pointing-control accuracy compare to instrument requirements?

• What types of payload, ground and spacecraft system margins exist and which must be monitored and controlled in real time?

• What expendables need monitoring during flight?

• Does the spacecraft subsystem use any onboard, closed-loop functions?

• What are the attributes of the spacecraft's data system?

• What processing must we do on the ground to support spacecraft operations?

• What is the heritage for each of the spacecraft's subsystems?

Consider an example of how a simple design decision affects operations:

The Galileo spacecraft was designed to take heat from the radioisotopic thermoelectric generators and use it to warm the propulsion system. This design saved weight and power, and it cost less to develop. But the spacecraft's operational characteristics tied together subsystems for propulsion health and safety, thermal transfer, and power. Operators had to check each command load to see how it changed power states and affected the propulsion subsystem. Engineers from power, thermal, and propulsion had to check each activity, even if only the payload instrument's states changed. For example, turning an instrument on or off caused the heat output of the thermoelectric generator to change.

This example shows that highly-coupled subsystems can make operating the system more complex and costly.

We must work with the end-users or customers to determine how, and how often, they require data from the payload. We also need to identify key operator tasks to operate the payload successfully. By understanding these data products and required actions, we can start designing how to operate the payload, as well as to retrieve and process the data.

We must understand how confident the end-users are about the products. Often, they don't know what they want until they see how the payload works in flight and what it observes. In these cases, we must develop baseline processes before launch and refine them after launch. For attached and deployable payloads from manned spacecraft, the payload must be mature enough to ensure no safety risks exist, either within a payload, or with another payload running simultaneously. We must develop early the procedures for payloads that we can maintain in flight, so we can use them during stand-alone and integrated crew training.

We also need to define the product's relationship to the payload data by answering the following questions:

• Is the product based on the payload's raw data or must we remove the payload instrument's signatures?

• Must the data be calibrated? How? Does it involve processing special calibration observations? At what rate do we expect the calibration files to change?

• Does the data need to be converted into geophysical units? How? Where do the algorithms for this conversion come from? Must the project generate them and update the mission database, as they become more refined?

• What are the formats and media of the payload's data products? Is there a community standard, such as the Flexible Image Transport System format used on all NASA's astrophysics missions?

• What ancillary data must we provide so the end-user can interpret the payload data—spacecraft position and attitude, ground truth, or crew commentary?

• Who processes the payload data—project or end user?

• How is the processed data archived—through the project or end user? How is quality of the product controlled?

• What, if anything, must the project archive after the flight phase is over? How long must information be stored?

Planners and payload engineers must consider these issues jointly to understand operationally what will occur during flight

Step 3. Identify Ways to Accomplish Functions and Whether Capability Exists or Must Be Developed

At this level, many functions and the ways to do them are straightforward. For example, to track an interplanetary spacecraft, we use NASA's Deep Space Network. For other functions, we must identify options and describe them. For example, to determine a spacecraft's orbit, we might use the Global Positioning System and automated procedures on board, or we might track the spacecraft from the ground and calculate its orbit on the ground. Mainly, we must decide where the prime responsibility for each function lies—onboard autonomy, ground-based operators, or automated functions. Then we must review our decisions in light of the capabilities on board and on the ground, as well as how critical the action is.

To understand options, try building a table that contains the operations functions which apply to the mission's database and space element's avionics. Then, identify whether the avionics (automated) or the mission operations system are to do each function. If functions must be done on the ground, further determine whether the hardware, software, or operators should complete it. If a function could be done in more than one place, describe what to do in each place and options for doing it. Table 14-2 shows how such a table would look.

If the ground hardware and software do something, ask, "Could the avionics partially or completely do this function and lower the mission's life-cycle costs?" For example, if we were considering orbit determination, we'd ask, "Could we determine the spacecraft location within the avionics?" Then, we'd look at the accuracy of the GPS system, check the cost of GPS receivers that are flight qualified, and do a first-order estimate of the change in life-cycle costs compared to a more typical approach. Don't forget that the costs of tracking facilities are important in this type of trade. The longer the mission, the more ground systems cost

Step 4. Do Trades for Items Identified in the Previous Step

For the options identified in step 3 that drive either performance or cost, a small group of operators, crew and designers need to do trades and decide how to carry them out. At this point these trades should involve areas that are very costly, controversial, or not well understood. In some cases, we may develop an operations scenario for each option to describe it in detail. Usually, these trades result in a traditional allocation of

XABLE14-2. Identifying Where to Carry Out Functions. Using a table similar to this one helps us identify options for carrying out mission operations. We assume functions not included In table are done on the ground. As you evaluate each function, place a check mark in the table to show where you complete the function.

XABLE14-2. Identifying Where to Carry Out Functions. Using a table similar to this one helps us identify options for carrying out mission operations. We assume functions not included In table are done on the ground. As you evaluate each function, place a check mark in the table to show where you complete the function.

MOS Function

Where Accomplished

Spacecraft Avionics


Mission Planning

0 0

Post a comment