# Presentation: 948832

## Lessons Learned In Developing Multiple Distributed Planning Systems for the International Space Station (ISS)

**Theresa G. Maxwell**
- NASA Marshall Space Flight Center
- Flight Projects Directorate
-  Ground Systems Department
- 256-544-2232
- theresa.maxwell@msfc.nasa.gov

## Scope of Paper

***Lessons Learned*** while developing multiple planning systems for the International Space Station (ISS)
- From the perspective of a system developer
- Payload Planning System (PPS) at NASA’s Marshall Space Flight Center (MSFC)
- Experiences and observations since 1987
- Includes inputs from planning system developers at NASA Johnson Space Center (JSC)
- Focus is *coordination* across systems so they can work together to support ISS “distributed planning”

## What is “Distributed Planning”?

- Multiple organizations participate in developing a single integrated plan
- “Pieces” developed by the distributed experts
- Partner/segment plans
- Systems plans
- Payload plans
- Pieces then integrated
- _ISS Planning participants:_
- NASA Johnson Space Center
- NASA Marshall Space Flight Center
- Russian Aviation & Space Agency
- National Space Development Agency of Japan
- European Space Agency
- Canadian Space Agency

**Pre-Increment Execute Planning Product Tree**

**GR&C = Ground Rules & Constraints**
**OOS = On-Orbit Operations Summary**

## Why Multiple Planning Systems?

**Why Multiple Planning Systems?**

- Each planning system is tailored to the needs of its home site:
- Supports allocated planning functions
- Systems versus Payload focus
- Unique control center constraints
- Unique products to support operations
- Language considerations

**Integrated Planning**
**System (IPS)**

**Payload**
**Planning**
**System (PPS)**

**JEM Execute Planning System **
**(J-EPS)**
**J-PLAN**

**Operations Preparation and Planning System (OPPS) **

**Scheduling and Planning System  (SPOM) **

***Interface***
***Files***

**ISS Planning Systems**

***NASA JSC***

***NASA MSFC***

***NASDA***

***ESA***

***RASA***

## Challenges

- _GOAL_:  The various planning systems must effectively work together to produce a single integrated plan for ISS onboard operations
- Complicating factors:
- Each system controlled by a different agency/organization
- Unique operating environments and requirements at each site
- Some systems support multiple programs
- Different development schedules
- International development effort
- External dependencies (changes in operations concepts, onboard systems, other ground systems, etc.)

## Lessons Learned

- The Lessons Learned are grouped into five categories:
- Planning Concepts and System Requirements
- Sharing of Tools
- Interface Definition and Control
- Coordination of Development Efforts
- Applying Changes Across Planning Systems

## Planning Concepts & System Requirements

**Planning Concepts & ****System Requirements**

***Planning concepts (roles, processes, products, etc.) drive the requirements.  ***
***On ISS, these concepts have continually evolved.***
_**LESSON**__:  Recognize that planning concepts will change, and plan accordingly_
- Plan for this uncertainty in planning system budgets and schedules
- Phased development
- Adequate sustaining budgets
- Design flexibility into the software (functionality, report formats, etc.)

_**LESSON**__:  Involve the software users in all phases of development_
- To capture changes in planning concepts and requirements
- To ensure functionality and user interfaces meet their needs

## Planning Concepts & System Requirements

_**LESSON**__:  Agree on requirements allocations across systems early on_
- Which systems will implement which functions?
- Potential cost/schedule impacts if not decided early on
_*Example*_:  Early debates over allocation of certain payload planning functions to the JSC or MSFC planning systems – when finally decided, was almost too late to implement
_**LESSON**__:  Make firm decisions on languages early in requirements phase_
- In multi-national program, which languages to support?
_*Example*_*:*
- ISS began as “English-only” program
- Russian Cyrillic added after years of software development
- Software impacts to update fonts, displays, etc.
- Some systems funded for updates; others not

## Sharing of Tools

**Sharing of Tools**

***On ISS, all the planning systems utilize the Consolidated Planning System (CPS) component of the JSC software to some degree.  ***
_**LESSON**__:  Sharing of tools can yield significant benefits_
- Potential to reduce overall program costs
- Promotes commonality across systems
- Simplifies interface definition
- Benefits end-users (common displays, etc.)
- Encourages close coordination between developers
_**LESSON**__:  Sharing of tools requires compromise_
- Additional tool complexity to support multiple parties’ requirements
- Parties must jointly debate and prioritize proposed changes
- No party gets all they want; and must live with things they don’t like

## Sharing of Tools

_**LESSON**__:  Multi-party funding can facilitate requirements satisfaction_
- Helps to mitigate conflicts over use of limited development resources
_*Example*_*:*  Separate funding for MSFC-unique requirements on CPS
_**LESSON**__:  Decide on tool sharing early in the development process_
_*Example*_*:  *Retrofitting of CPS into MSFC Payload Planning System (PPS) caused significant rework
_**LESSON**__:  Need formal mechanisms for coordinating shared tool development_
- Multi-party participation in requirements definition, change approval, design reviews, software testing, and problem reporting/prioritization
_**LESSON:**__  Need an established export control process, with trained personnel_
- In multi-national program, must consider export control issues
- Established process allows time-critical shipments to be made on schedule

## Interface Definition / Control

**Interface Definition / Control**

***With multiple systems, the Interface Definition is the KEY to success.***
_**LESSON**__:  IT security issues may drive interface, so address them early on_
- Database interfaces vs. file exchange/drop boxes, etc.
_**LESSON**__:  Formally agree on definition via Interface Control Document (ICD)_
- Multilateral review/approval of any changes
- Commitment to meet the interface
- Baselining authority with multilateral representation
_**LESSON**__:  ICD development must support all individual system schedules_
- Adequate time between ICD baselining and software coding/deployment
- Review cycles must accommodate internal review processes at each site

## Interface Definition / Control

_**LESSON**__:  Beware an interface definition explicitly tied to one application_
_*Example:*_
- For ISS, interface files are tied to the CPS internal database structures
- Changes in data used only by the CPS (e.g., display formats) force a change in the interface definition
_**LESSON**__:  Document data integrity rules in the ICD_
- Include mandatory data fields, data validation rules, etc.
- Prevents “bad” data from entering the system
_**LESSON**__:  Document standards for user-controlled data_
- In planning systems, creation/naming of resources and activities to be planned/scheduled is under control of the software user
- Document user agreements on these to synchronize data across systems

## Coordination

**Coordination**

***Close coordination of the independent development efforts is mandatory.***
_**LESSON**__:  Establish regular communications forums_
- Monthly telecons, e-mail, periodic face-to-face meetings, etc.
- With multi-national program, consider time zone and language differences
_**LESSON**__:  Encourage participation in each other’s technical reviews_
- Can identify/resolve potential disconnects before they become problems
- Opportunity to share ideas
_**LESSON**__:  Need strong integration function to lead the coordination_
- One party should serve as prime coordinator
- Formal authority with multilateral representation to oversee/approve the coordinated plans  (_*Example:*_  for ISS, this is Ground Segment Control Board)

## Coordination

_**LESSON**__:  Need clear avenues for issue resolution_
- Define avenues throughout the development process,
- 	and on into operations
_**LESSON**__:  Need mechanisms to negotiate development/deployment schedules_
- All parties must commit to negotiated schedules
- Address all critical events:  ICD development, system deployments, etc.
_*Example:*_  ISS has a “Planning Facility Schedules Document”
_**LESSON**__:  Decouple individual development schedules to the extent possible_
- Individual development/deployment schedules not likely to line up
- Can cause major problems when interface definition changes
- Find mechanism which allows schedule decoupling
_*Example:*_  ISS utilizes “backward compatibility” and “Sync points”

## Coordination

- A _***Sync Point***_ is a specific version of the interface definition that all systems have agreed to meet by a certain date.  The software is _***Backwards Compatible***_ with the previous sync point during the transition period.

**Sync Point X**

**Sync Point Y**

**Transition Period**

*System upgrades to*
*meet new Sync Point*

## Coordination

_**LESSON**__:  Coordinate platform and COTS requirements as far out as possible_
- Mandatory if sharing software tools
- Prevents “surprises” which can impact schedules
- Accommodates long lead times for procurements and installation
_**LESSON**__:  Joint testing is required for successful software checkout_
- Cooperative effort between development and user organizations
- Perform end-to-end testing to simulate the operational environment
_**LESSON**__:   Joint effort is required to resolve operational problems_
- Problem may manifest in one system, but be caused by another
- Responsive development/user team is needed to identify, diagnose, and resolve operational problems

## Applying Changes Across Systems

**Applying Changes Across Systems**

***Because of their interdependence, ***
***changes tend to ripple across planning systems.***
_**LESSON**__:  Approve/fund changes across ALL affected planning systems_
- With separate funding sources, a change may not be approved/funded across all affected planning systems
_*Example:*_  Implementation of Russian Cyrillic was not funded system-wide
_**LESSON**__:  Consider impacts to planning systems when changing external systems_
- Planning systems are sensitive to changes in onboard systems and other ground systems
- Programs should consider impacts to planning systems when assessing other changes, and fund accordingly

## Conclusions

- Multiple planning systems can operate together in the development of a single integrated plan
- Other programs can learn from the ISS experiences
- _Over-riding lesson_:  Need to take a ***global perspective**** * in requirements, budgets, change approval, and system coordination