The ISHM project plan contains a good analysis of the state of the art outside NASA and has a well-characterized and specific set of objectives. Integration of the objectives into operational missions a still a somewhat ambiguous matter to the committee.

In the ISHM project, mid-TRL historical developments are used, with limited flight demonstrations, to develop flight heritage technologies that can be inserted into the Constellation Program. The technical approaches are solid, if somewhat limited. A good assessment has been made of what is required for the maturation of ISHM technologies such that actual mission program insertion can occur.

There was no clear visibility for the roadmap and risks associated with the ISHM effort to expand and enhance the limited scope of developments underway to include the addition of new systems and subsystems. This seems, in part, a result of what appears to the committee to be limited buy-in from the customer, despite significant performance parameters assigned to this project for risk reduction in Constellation. For example, a full assessment of failure modes for a complete validation of models was described as needing 20 or so more hot-fire tests of an Ares I that were not included in either the project budgets or time lines.

A roadmap for building the end-to-end ISHM and its integration into the end-to-end flight controls would be a critical element in moving this rating from a yellow to green flag. Also important to effective transitioning would be a more detailed roadmap for flight qualification for the eventual end-to-end model.

If effectively developed, integrated, and validated through lunar experience, ISHM technologies will provide critical risk management tools for future missions. Automated system health monitoring and management technologies are well aligned with the VSE, and they are critical to the Constellation requirements. These technologies are also clearly enabling for the Mars mission.

However, if the critical risk management tools are to evolve between now and a Mars mission, NASA is encouraged to look at ways to increase safety (reliability) margins in vehicle design, not simply to improve the control and monitoring software. While this project is clearly aligned with the VSE, the approach may not be complete enough to allow a transition to future elements of the VSE without a great deal more work.

The primary objective of the Autonomy for Operations (A4O) project is to provide software tools to maximize productivity and minimize workload for mission operations by automating procedures, schedules of activities, and plans. The primary customer for the technology is Constellation. The technology will provide mission operations software capabilities for Constellation mission operations, onboard control, crew assistance, and robotics. The key technologies are reusable building blocks, the automation of mission operations functions, and support for human interaction. Current testing opportunities have primarily focused on using data from the International Space Station (ISS).