ABSTRACT. The International Space Station (ISS) program is heavily dependent on the concept of distributed planning. Within the payload planning community, the concept of distributed planning places a great deal of responsibility in the hands of the science users. This approach to planning is very different from that used within the current U.S. Space Shuttle and Spacelab programs, where much of the responsibility for planning resides with the control center personnel. In the Shuttle and Spacelab programs the control center personnel interface with the science users to obtain the requirements for the operations to be scheduled. These requirements are then translated by the scheduling experts into the format required for use by the scheduling software. Within the ISS program, the interface to the control center personnel has been radically altered. The users will assume the responsibility for submitting requirements in the format required for use by the scheduling software. Therefore, it is extremely important that requirements modeling software be provided which enables non-scheduling experts to easily and accurately define their requirements. The requirements modeling process is further complicated by the very complex nature of the ISS systems against which requirements must be defined. The concept of explicit and implicit resources has been developed to support these two key requirements. This paper defines and describes the concept of explicit and implicit resources, provides examples of scheduling requirements implemented using explicit and implicit resources, and discusses the software currently being developed to support this concept.

The distributed planning environment within the International Space Station (ISS) program presents unique opportunities for user community participation in the development of operations plans and products. (See reference 1). These opportunities, while eagerly embraced by the user community, bring with them additional responsibility and complexity. In past programs, such as the Space Shuttle and Spacelab, much of this responsibility and complexity was shielded from the user community by the control center personnel dedicated to the development of operations plans and products. A drawback of this approach to the development of plans and products was that it required a high level of interaction between the user community and the control center personnel which in turn resulted in higher operations costs to the program. The environment of the ISS program drives the need for user community involvement in the development of operations plans and products. This involvement satisfies user community requirements for participation in the planning process, and achieves efficiencies in the operations costs of the ISS program.

User involvement in the planning process does not mitigate the control center responsibility for insuring the feasibility and safety of the resulting operations plans and products. The major obstacle which must be overcome is how to convey detailed knowledge between the control center personnel and the user community. The control center personnel have the detailed knowledge of the station systems, and must be capable of defining the characteristics of these systems such that they can be understood and used by the general user community. The user community has the detailed knowledge of the operations that must be scheduled and performed, and must be capable of defining the requirements for these operations in a manner that satisfies the feasibility and safety concerns of the control center personnel. A way of accommodating this exchange of data, while providing confidence in the data provided, is to limit the opportunities for introducing incorrect or incomplete data. The use of implicit and explicit resources fills this need by hiding the complexities of station systems from the user, while insuring that requirements are levied against the appropriate station systems. Data consistency and completeness is enhanced through the modeling software used for defining scheduling constraints and scheduling requirements.

In order to fully grasp the concepts described within this paper, it is necessary for the reader to have a clear understanding of the terminology used to explain the proposed concepts. The following are key terms and their definitions.

Explicit Resource - A resource defined as a constraint or limitation on scheduling which is directly requested by a user in the definition of scheduling requirements.

Implicit Resource - A resource defined as a constraint or limitation on scheduling which is not directly requested by a user in the definition of scheduling requirements, but which is derived from the requirements as defined by the user.

Functional Relationship - A mathematical expression which defines the requirements for one resource based on the specified requirements for some other resource.

Modes - The representation of the possible operating states for a given piece of equipment. Associated with each defined operating state is the definition of the resources that are utilized by the particular piece of equipment.

The basic premise of the explicit and implicit resource concept is to hide the complexities of the station systems from the user in the definition of scheduling requirements. Explicit resources are defined within the modeling software to correspond to the physical and logical resources that a science user can relate to when defining requirements for scheduling. The requests for these explicit resources are interpreted by the modeling software. Through this interpretation, the modeling software associates the appropriate implicit resources with the user's scheduling requirements. In this manner, the user's scheduling requirements account for all of the necessary requirements without the user ever having to have a detailed understanding of the station systems required to support the defined operations. Without this capability, the user would be required to include all of the necessary resources on a given model. There are three primary functions associated with the use of implicit and explicit resources: 1) resource definition, and 2) requirements modeling, and 3) scheduler formatting.

3.1 RESOURCE DEFINITION

The resource definition function is performed first to establish and define the context within which the scheduling requirements can be defined. As such, this function must be access controlled to insure that the user community has a consistent and accurate set of constraints to use when defining requirements. The resource definition function is generally performed by the control center personnel.

The first step within this function is the identification of the station systems and their components that must be considered during scheduling. These systems and their components are modeled within the planning system as nondepletable, depletable, or condition resources.

A nondepletable resource is a resource whose availability is temporarily changed for the duration of its use. Power is a good example of a nondepletable resource. When an operation is scheduled which uses power, the availability of power is temporarily decremented to account for the power consumed by the operation. Once the operation is completed, the availability of power is returned to its original state.

A depletable resource is a resource whose availability is permanently changed as a result of its use. Nitrogen is a good example of a depletable resource. When an operation is scheduled which uses Nitrogen, the availability of the Nitrogen resource is permanently changed as a result of the operation.

A condition resource is a resource whose availability is specified in binary terms, which can be used to support an infinite number of concurrent activities. Sun periods are good examples of a condition resource. Any number of operations can be scheduled which have a requirement to operate during Sun periods. The execution of these operations in no way affects the availability of Sun periods.

Once the constraining resources have been identified, a decision must be made as to how the resources are to be defined within the planning system. Each resource must be defined as either an implicit resource or an explicit resource. A resource cannot be defined as both, as this could result in double booking the resource during the requirements modeling phase. An exception to this rule is the designation of condition type resources. This rule does not apply to these types of resources due to the fact that they are not magnitude constrained.

In addition to defining a resource as either explicit or implicit, the definition must also take into account the complexities of the resource and the relationships or interdependencies with other resources. Functional relationships and modes are the two primary means of satisfying these requirements.

Functional relationships are used to account for the use of one or more resources through the use of other resources. The following examples illustrate possible types of functional relationships and how these relationships could be applied to actual resources.

Example 1 - Use of a resource is defined as a function of the use of another resource over time. In this example, the resource Energy is defined in terms of the duration and magnitude of the resource Power.

usage (x) = f(usage(y), time)

Energy = Power x Time

Example 2 - Use of a resource is defined as a percent of the use of another resource. In this example, the resource Avionics Air Cooling is defined in terms of a percent of the resource Power.

usage (x) = f(usage(y), factor)

Avionics Air Cooling = Power x 40%

Example 3 - Use of a resource is defined as the sum of the use of some number of other resources. In this example, the use of power on an electrical bus is defined as the sum of the power used by each of the racks connected to the bus.

usage (x) = f(usage(y₁), usage(y₂), usage(y₃),...,usage(y_n))

Bus power = Rack A Power + Rack B Power + Rack C Power

Modes are somewhat more complicated than functional relationships in that they not only account for the other resources that are used, but also take into account the magnitudes of the resources that are required. Different modes must be defined to account for the different combinations of resources that can be used, as well as to account for differences in the magnitudes of any given resource. The following example illustrates the definition of modes.

Example 4 - A piece of equipment has three operational modes. Each mode requires a particular set of resources, where the magnitudes of the resources may vary from one mode to the next. Table 3.1-I illustrates the definition of modes for this example piece of equipment.

3.2 REQUIREMENTS MODELING

The requirements modeling function is performed to represent the constraints and support necessary to execute a particular operation. These requirements can typically be categorized into the following areas:

Performance Requirements - Requirements that define the performance window, number of performances, and frequency of performances of an operation to be scheduled.

Resource Requirements - Requirements that specify the magnitude and duration of the resources needed to perform an operation.

Temporal Relationship Requirements - Requirements that specify a timing or sequencing relationship between one or more operations. These include requirements for predecessor, successor, concurrency, and avoidance relationships.

This paper deals only with the specification of Resource Requirements. Collection of requirements for the other categories is out of the scope of this paper.

The concept of explicit and implicit resources provides a very powerful way of simplifying the user's definition of scheduling requirements that fall into the category of resource requirements. Two key components required to support or implement this concept are: 1) Functional Relationships, and 2) Modes. The Functional Relationships and Modes provide a convenient way of defining requirements for one or more resources through the user's requirement for some other resource. In this manner, when a user explicitly defines a requirement for a specific resource, requirements for other resources are implicitly appended via the Functional Relationships and Modes associated with the specified resource. An example might be the user's requirement for a piece of equipment that when operated requires power, heat dissipation, and data resources. Refer to figure 3.2-1 for a pictorial representation of requirements specified in this manner.

The example in figure 3.2-1 illustrates the user's definition of requirements for explicit resources; e.g., the user's requirement for equipment A and equipment B. Modes, which identify the possible operating states, are pre-defined for these two pieces of equipment. The Modes and Functional Relationships provide the links to the complete set of resources required to support the operation of the equipment in the state as specified by the user. It is important to note that the user does not define the modes for a particular piece of equipment, but merely selects from the possible set of modes that were created via the resource definition function. It is also important to note that the user can only define requirements in terms of the resources which have been defined as Explicit Resources; i.e., the user cannot directly specify requirements for resources defined as Implicit Resources.

3.3 SCHEDULER FORMATTING

While the resource definition and requirements modeling functions make extensive use of implicit and explicit resources, the scheduling function deals with individual resources and has no knowledge of whether a resource was explicit or implicit in terms of the definition of resources and/or requirements. Therefore, it becomes necessary to take the abstract representations of implicit and explicit resources and convert them into individual and unique resources that can be used by the scheduling engine. Explicit resources that have no associated implicit resources are extracted on a one-to-one basis. Explicit resources that have relationships to one or more implicit resources are extracted on a one-to-many basis.

The following example provides further clarification of the explicit and implicit resource concepts as presented in this paper. References to specific resources and their capabilities are for example purposes only, and should not be considered as official statements of ISS vehicle capabilities, limitations, or implementations.

4.1 EXAMPLE RESOURCE DEFINITION

The Resource Definitions that apply to this example are identified in Table 4.1-I.

In order to support scheduling, all of the above resources must be defined and utilized in requirements modeling. In the case where explicit and implicit resource capabilities exist, additional resource definition information must be supplied to account for the Modes and Functional Relationships. This information is shown in Table 4.1-II.

4.2 EXAMPLE REQUIREMENTS MODELING

In this example, a user needs to define requirements to install, grow, and remove a sample in the biology facility. The user determines that the installation procedure takes 30 minutes, the growth procedure takes 20 hours, and the remove procedure takes 1 hour. Figure 4.2-1 illustrates how the user would define these requirements using the explicit and implicit resource concept. It also provides for comparison the larger set of information the user would have to provide if all resources had to be explicitly requested.

4.3 EXAMPLE SUMMARY

From the simple example illustrated in figure 4.2-1, it is obvious that the use of explicit and implicit resources simplifies the requirements modeling process for the user. The possibility for errors or inconsistent data significantly increases when all resources must be explicitly requested by the user. These errors and/or inconsistencies result from the fact that the user must ensure that all appropriate resources have been requested, and that the values of all related resources are consistent. These problems are alleviated when explicit and implicit resources are utilized, since all of the relationships and interdependencies are accounted for in the definition of the resources.

While the use of explicit and implicit resources simplifies the specification of user requirements, it results in added complexity in the definition of resources. This additional complexity is acceptable since the resource definition function is performed in a controlled fashion by the personnel with the knowledge and expertise of the systems and hardware being defined as resources. The additional complexity is also justified by the fact that these resources are defined early in the planning process, and are only modified when configurations or capabilities change. The burden of this additional work is levied on the experts and, therefore, shielded from the general user community.

The concept of implicit and explicit resources relies heavily on the development and implementation of capabilities within the ISS planning systems. This work is currently funded by the ISS program and included in the development of the Payload Planning System (PPS). (See reference 2.) The PPS is actually a suite of applications which are being developed to support the distributed planning needs of the general user community, as well as the control center personnel responsible for payload planning product development and integration. The PPS is comprised of six major components, all of which exchange data with one another through a single database. This single database also provides the mechanism for exchanging planning data with the planning systems utilized by the international partners and the systems planning community. The PPS architecture is shown in figure 5-1.

The following are brief descriptions of each of the six components, as well as a description of the database used for the exchange of planning data.

User Requirements Collection (URC) - The URC provides the capabilities required to define resources, collect user requirements, and transform user requirements into the format required for use by other PPS components.

Consolidated Planning System (CPS) - The CPS provides the capabilities required to develop detailed schedules based on the user requirements and resource availabilities. CPS also provides the resource distribution and schedule integration capabilities necessary to support distributed planning.

Planner - The Planner provides the capability to develop high-level plans based on user requirements and projections of resource availabilities. These plans satisfy long-term planning needs and provide guidance and direction to the CPS for use in generating detailed schedules.

Data System Routing and Configuration (DSRC) - The DSRC provides the capabilities required to schedule the routing of data through the onboard systems, and to determine and plan the configurations of the onboard data systems required to support the routing of the data.

Flight Dynamics Planning and Analysis (FDPA) - The FDPA provides the capabilities required to generate and propagate space station and earth-to-orbit vehicle ephemeris data.

Product Generation (PG) - The PG provides the capabilities for the user community and control center personnel to view and print planning data.

External Data Repository (EDR) - The EDR provides the database of approved planning data. This database supports the exchange of data between planning systems, as well as the exchange of data between the components of PPS.

While each component of PPS performs key functions, it is the URC component that performs the functions necessary to implement the concept of implicit and explicit resources as defined in this paper. URC supports the definition of resources, the collection of user requirements, and the transformation of those requirements into the format required for use by the other components of PPS.

The implementation of the explicit and implicit resource concept should simplify the requirements modeling process for the user community, while at the same time increasing the confidence and reliability of the data provided. The examples provided within this paper illustrate the manner in which the complexities of the systems can be hidden from the user community. The implementation of these concepts relies heavily on the development of new and better software tools.

1. Hagopian, J., Maxwell, T., "An Approach for Implementing Distributed Planning for Space Station Payload Operations", 1995 American Institute of Aeronautics and Astronautics Space Programs and Technologies Conference, Huntsville, AL, September 26-28, 1995.
2. National Aeronautics and Space Administration, Payload Planning System (PPS) Software Product Document, System Specification (SS) Revision B, SW683-70256-1, March 31, 1996.