A NASA-led effort is under way at Kennedy Space Center to design, develop and implement a new Checkout and Launch Control System (CLCS) for the Space Shuttle with the capability to support future launch vehicles. The first major milestone of this five-year effort will be reached March 28 with the opening of an experimental control room in the Launch Control Center.
Development of CLCS incorporates a progressive and innovative approach that involves the user community to the fullest extent.
"Customer involvement at every phase is crucial to our success," KSC Director Roy Bridges observed. "The new Checkout and Launch Control System is a ‘must-do-and-deliver’ project for us. We cannot support our mission without it."
The CLCS is the successor to the Launch Processing System (LPS). The Shuttle version of the LPS dates back to the early 1970s and is the successor to the LPS developed for the Apollo program. Illustrative of how advanced computer technology has become in the brief time span since the Shuttle LPS became operational is the amount of memory in a single LCC firing room minicomputer. The average new home computer has 16 megabytes of Random Access Memory (RAM) - 250 times more than the average LCC computer.
The CLCS will feature several major improvements over the LPS, including the capability to monitor more than one orbiter from the same firing room. Incorporation to the fullest extent possible of commercial off-the-shelf hardware and software will reduce system operating costs by 50 percent while making it easier to add upgrades.
The CLCS will be implemented in increments and is scheduled to be fully operational by September 2001. A NASA/contractor team, led by Retha Hart from the KSC Shuttle Processing Directorate, is developing the system. Major participating contractors include United Space Alliance (USA), the Space Flight Operations Contractor; I-NET, the Engineering Support Contractor; and Lockheed Martin of the Johnson Space Center-based Mission Support Contract.
"Because of the importance of the project to the future of KSC," Bridges said, “I have asked the CLCS team to report directly to me."
The CLCS was conceived in 1996 by a specially-formed team working under the charter of Shuttle Processing Director Robert Sieck. One of the constraints on previous efforts to modernize the Shuttle LPS was the requirement to retain the computer language GOAL ( Ground Operations Aerospace Language).
GOAL is a KSC-unique language which has driven checkout and validation requirements due to its design. A major concern about GOAL was that simple displays are created from the same programs that execute critical commands. As a result, even the simplest of changes require rigorous and exhaustive testing to insure the critical command function remains intact. The LPS Upgrades Review Team chartered by Sieck concluded that the new launch processing system needed to be free of the constraints imposed by GOAL. After further refinement, the team came up with an operational concept that is now being implemented as CLCS.
"CLCS is committed to providing a system that allows Shuttle processing to be achieved efficiently, flexibly and at a reduced cost over the current system," said Project Manager Retha Hart.
The CLCS concept emphasizes the universal rather than the specialized. With the LPS, specific firing room consoles are assigned to specific Shuttle or ground support systems. The CLCS will feature generically-configured consoles which can handle the checkout and test of any Shuttle system. Key capabilities will be:
* Command and monitor data will be separated. Monitor data can be distributed free of the risk of issuing inadvertent commands. Launch team members will be able to view data in their office instead of having to go to the control room. (Note: CLCS terminology refers to the firing room as an Operational Control Room, or OCR);
* Multi-orbiter control. More than one orbiter will be controlled from the same room. With LPS, one firing room is assigned per vehicle per flow. With CLCS, a single control room can be divided into multiple flow zones, each linked to a different orbiter under test. After the vehicle is fully stacked in the Vehicle Assembly Building, one control room will again be assigned to that Shuttle.
* Multidiscipline testing. With CLCS, test engineers will be able to monitor and control multiple systems from the same console.
* Consolidated data. Data currently residing on separate computer networks will be integrated into a single data stream available to all CLCS users. For example, weather data from the pad now being stored in the Processing Control Center will be incorporated into CLCS.
* Integrated complex/facility control. Control of facility systems will be combined into the control rooms, instead of being located separately in the Complex Control Center on the 1st floor.
* Local commanding operations. Subsystem testing can be performed locally at the test site with minimal control room support. An engineer with a laptop computer can conduct an orbiter system test in one of the Orbiter Processing Facility bays without requiring the presence of an engineer in the LCC control room, as is the case with the LPS.
* Program-compatible data. CLCS will incorporate data formats and protocols compatible with other NASA centers, making it easier for different centers to share data and more easily compare information.
The user community has been involved with CLCS development since the beginning. "We are very customer-oriented," noted Hart.
Acting as full-time liaisons for the user community are Jeff Wheeler, NASA, and Chris Best, USA. Wheeler and Best regularly involve representatives from virtually every directorate at KSC, from payloads to Shuttle operations, including the NASA Test Director (NTD) world, that interact with the current system. "We are constantly trying to involve the user in the process so that when we reach the end product we have something that the user is comfortable with," Wheeler said.
The user community is closely involved in the design of the Human Computer Interface (HCI), which refers to the configuration of the consoles in the firing room, from keyboards to monitors to the software that will allow checkout, test and launch of the Shuttle.
Wheeler pointed out some of the other issues which also must be resolved: Preserving "legacy" systems, which refers to systems such as the Operational Television (OTV) network and Operational Intercom System (OIS) that predate CLCS and are being retained; and identifying what it takes to maintain a console configuration once it is established.
CLCS will provide the same functionality as the current LPS, but with a new architecture. This distributed architecture, based on commercial off-the-shelf technology and industry-standard hardware and software, will provide flexibility and automation enabling significant reduction in Shuttle operations costs.
CLCS will produce a fresh new look for the control rooms. All aspects of the control room consoles will be replaced, from the computers to the display monitors and keyboards to the shells in which they are encased. The very layout of the firing room is up for discussion and could end up completely different from the present layout.
No changes will be made on the vehicle side of CLCS -- the interface between Shuttle hardware/software elements and the new processing system. This was one of the ground rules established by the CLCS project personnel.
One of the biggest challenges KSC faces in upgrading the LPS is maintaining the Shuttle launch manifest while transitioning from the old to the new, said Tom Fleming, a member of the CLCS project controls staff. To achieve CLCS without imposing delays, the new processing system will begin installation in firing room 4 and then move through firing rooms 3 and 2. The rooms will be renumbered under CLCS, with LPS firing room 4 becoming CLCS Operational Control Room 1 (OCR 1). A conference room located next to firing room 4 will become part of OCR 1. When firing room 2 has been converted into OCR 3, the system will be at full capability. LPS Firing Room 1 will be retired from operational use.
Implementation of CLCS also incorporates an innovative philosophy. Rather than delivering a final product by a certain date, the new launch system will be brought online in six-month increments over the next five years. "Each delivery provides a new capability," Hart said. It can be actual equipment or simply modifications to a facility to prepare it for CLCS. The most critical deliveries will be of software elements that provide a new or improved capability.
The milestones are named individually after historic launch vehicles, with the March 28 delivery called Juno. Juno will mark the establishment of an experimental control room in Firing Room 2 of the LCC featuring two different prototype consoles for the user community to experiment with. The new technology being infused into CLCS is evidenced by flat-panel monitors featured on one prototype. "This is indicative of the way we will deliver the system: Build a little, test a little, deliver a little, until the entire system is complete," Hart said.
The CLCS system is scheduled to be fully operational by September 2001. First operational use will occur in March 1999 at the Hypergol Maintenance Facility (HMF) in the KSC Industrial Area, and the first CLCS-supported orbiter flow will begin in August 2000.
"It is important that the Space Shuttle launch team have the tools needed to execute safe and successful launches," said Shuttle Operations Director Robert Sieck. "With this new tool, the CLCS, our team will be able to maintain its reputation as the ‘greatest launch team in the universe’ well into the 21st century."
The CLCS Web Site is at http://lpsweb.ksc.nasa.gov/CLCS/