Short- and long-term planning by operators, augmented with automated tools

functional responsibilities to the flight crew, avionics, and operators. The key here is to look for approaches that truly minimize life-cycle cost without jeopardizing the safety and reliability of the mission and systems.

Step 5. Develop Operational Scenarios and Flight Techniques

Operational scenarios are key to an operations concept. A scenario is a list of steps, and we can often describe a mission operations concept with several dozen top-level scenarios. Typically, we generate three types of scenarios:

• User Scenario—How the user interacts with the system elements and receives data.

• System Scenario—How systems and subsystems within an element work together.

• Element Scenario—How the elements of the space mission architecture work together to accomplish the mission.

During the early study phases of a mission, users develop a scenario to show how they want to acquire data and receive products from the payload. For a science mission, the user would be the principal investigator or science group or, for a facility spacecraft such as the Hubble Space Telescope, an individual observer.

We create a system scenario after we've developed the operations architecture. Here, we emphasize the steps within a process needed to conduct the mission. Finally, during element design, we expand these system scenarios to include more detailed information and subsystems. Once we have created scenarios for the user, system, and element, we must integrate them to understand what happens throughout the mission and make sure we've included all key activities and eliminated overlaps. The scenarios give us our first look at how our system operates as a unit to produce the mission data.

The mission concept, Mission Operations Plan, and design of the space and ground elements are closely related. As design proceeds, we should keep cost in mind and recognize that engineers normally focus on the technical challenge, with costs secondary. All participants in the conceptual design not only must keep cost in mind, but should view it as a design variable. As designs mature for all elements of the space mission architecture, we must do trade studies to get the most cost-effective mission design. If the budget is constrained, which it usually is, we must look for ways to reduce costs by changing the mission concept, mission requirements, and potentially, the mission's overall objectives.

Step 6. Develop Timelines for Each Scenario

Now we can add times needed to do each set of steps and determine which steps can run in parallel or have to be serial. This information becomes a source of derived requirements for the mission operations system's performance.

Many different timeline tools are used. None is standard, but many are modified from commercial, off-the-shelf software. Most missions use the same timeline tools for operational scenarios and activity planning. For many smaller payload users, asking for planning support from the MCC is less expensive than investing in a parallel planning system. These requirements must fit within the scope of the agreements among the program, operations, and the user. In many cases, the MCC has already required information that it can make available to you. In other cases, teams must generate ancillary data or change plans to fit unique needs for payload planning. If these changes are extensive, a separate planning system may be the effective solution.

Step 7. Determine the Resources Needed for Each Step of Each Scenario

Once we've developed scenarios, we may assign machines or people to do each step. This choice is obvious for many steps, but people or machines may do others, depending on performance requirements and available technology. The trend is toward automation on the ground and autonomy in space. We must be careful to identify, as specifically as possible, which tasks the flight crew should do.

Having allocated resources (hardware, software, or people), we must assign steps to hardware and software within data-flow diagrams. For steps assigned to people, we select an existing organization or develop an operational organization and assign steps and functions to teams.

At this point, we examine each step to which we've assigned an operator and ask, "Can this process be automated to eliminate the operator?" How? Allow a person to do something only when the complexity or flexibility or life-cycle costs mandate human involvement. Don't accept the idea that we need a person because we've always done it that way. Technology is advancing so rapidly that a machine may very well do now what a person had to do on the last mission. Through this process, we'U also discover areas on which to focus research and development funding for possible automation in future missions.

Step 8. Develop Data-flow Diagrams

System-engineering tools can convert machine steps into data-flow diagrams showing processes, points for data storage, and interrelationships. They also generate a data dictionary that ensures a unique name for each process or storage point in the data flow. These computer-aided systems engineering tools then generate information you can use for development One of the most effective actions you can take to reduce overall life-cycle cost is to understand where data originates and the flow it takes throughout your system to the end user or customer and to your archive. Figure 2-2 in Sec. 2.1.1 shows a top-level data-flow diagram forFireSaL

Step 9. Characterize Responsibilities of Each Team

Once we've defined functions and processes, gathered the people-related steps, and formed an organization around them, we can assign teams to the steps and analyze the organization to establish operational interfaces. Generally, the more inputs we get from different teams, the more complicated, costly, and slow the operations organizations are. The goal of this step is to identify the number of people required to do mission operations during each mission phase. We'll use this information to estimate the cost of operations. We should be open to approaches and trade-offs that reduce overall life-cycle cost

Step 10. Assess Mission Utility, Complexity, and Operations Cost Drivers

To assess mission utility, we follow the overall process defined in Sec. 33. To do so early in design may require flexible simulations, in which input parameters and system parameters have a range of values. Operational simulations that produce outputs which meet mission objectives are candidates for the Mission Operations Plan. As the plan matures, assessing mission utility yields confidence in the design or highlights shortcomings for re-design.

To assess operations complexity and how it drives mission operations cost, we use a complexity model that shows the relationship between operational parameters and full time equivalent operators. This model requires us to evaluate each of our operational activities as low, medium, or high complexity. Then, based on previous missions of the same class, the model produces the number of operations personnel. During design, this model gives us rules for trade studies to reduce operations costs. Boden and Larson [1996, Chap. 5] describe this model in detail. See Sec. 14.3 for a summary.

Step 11. Identify Derived Requirements

At this point, we've updated the Mission Operations Plan with new information associated with the mission operations concept, requirements, existing and new capabilities, scenarios, timelines, and the anticipated life-cycle cost Now, we can identify new or derived requirements necessary to reduce cost and complexity and enhance the safety and reliability of operations. We should document these derived requirements in the Mission Operations Plan, being careful to identify what is to be done—not how—and why the requirements are necessary. Then, we should communicate the derived requirements to the group that develops the mission's conceptual design and negotiate them into the requirement baseline.

Step 12. Generate a Technology Development Plan

The technology to support a mission operations concept may not exist or may not be focused and prototyped appropriately for mission approval. With each iteration of the Mission Operations Plan, we must identify needed or risky technology, sp someone can develop the technology or create work-arounds.

Step 13. Iterate and Document

The last, and usually most painful, step is to document the results of the iteration through the Mission Operations Plan to develop a baseline from which we can continue to improve and reduce life-cycle cost The documentation should include at least these elements:

• Requirements and mission objectives

• Key constraints—cost, schedule, and technical performance

• Assumed mission and flight rules

• Scenarios—described in terms of functions

• Timelines for each key scenario

• Ground and flight crew tasks

• Organization and team responsibilities and structure

• Hardware and software functions

• Data-flow diagrams

• Payload requirements and derived requirements

Remember that this document is the basis for communicating the overall operations approach to users, operators, and system developers. If done and used properly, it can help save millions of dollars in the design and operation of space systems. We strongly recommend keeping the Mission Operations Plan in electronic form and making it readily available to all members of die conceptual design team, so they can keep the big picture in mind as they further develop concepts, systems, and approaches. The earlier the first Mission Operations Plan appears, the greater the leverage for reducing life-cycle costs.

Now that we understand how to develop a Mission Operations Plan, we need a more detailed understanding of what mission operators do, so we can create a better and more detailed plan.

0 0

Post a comment