Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Mission manager software”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 109 records · Page 6

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Emulation of Core Flight System Applications for Flight Software Development and Validation

The Mars Sample Return (MSR) campaign is an unprecedented attempt in the return of Martian samples back to Earth. The ascent from the surface will be performed by the Mars Ascent Vehicle (MAV), a critical element in the mission that National Aeronautics and Space Administration (NASA) Marshall Space Flight Center (MSFC) is developing. To this end, innovations in flight software development, verification, and validation are occurring. The MAV flight computer will run Core Flight System (cFS), an open-source software environment developed by NASA Goddard Space Flight Center (GSFC). NASA Marshall’s MAV Mission and Fault Management (M&FM) Team has implemented an emulation of two applications of this architecture: Limit Checker and Stored Command. Using an emulation of the functionalities of these applications allows for rapid prototyping of table-based algorithms. Further, M&FM is leveraging an in-house, low-fidelity but high-throughput State Analysis Model (SAM), an integrated MATLAB Stateflow Plant and Software model. This model is run in parallel with the cFS emulation for full flyout testing of the M&FM algorithms, verification of intent of these algorithms, and for future auto-generation of application-ingestible M&FM tables. The tables can then be delivered to the MAV Flight Software (FSW) team in a seamless process, reducing the cost of traditional FSW development and the risk of starting M&FM FSW development at later points in the NASA program life cycle.

Cody Wheeler↗

Onboard Science Data Analysis: Opportunities, Benefits, and Effects on Mission Design

Much of the initial focus for spacecraft autonomy has been on developing new software and systems concepts to automate engineering functions of the spacecraft: guidance, navigation and control, fault protection, and resources management. However, the ultimate objectives of NASA missions are science objectives, which implies that we need a new framework for perfoming science data evaluation and observation planning autonomously onboard spacecraft.

spacecraft autonomy observation planning science d↗

Assurance of Fault Management: Risk-Significant Adverse Condition Awareness

Fault Management (FM) systems are ranked high in risk-based assessment of criticality within flight software, emphasizing the importance of establishing highly competent domain expertise to provide assurance for NASA projects, especially as spaceflight systems continue to increase in complexity. Insight into specific characteristics of FM architectures seen embedded within safety- and mission-critical software systems analyzed by the NASA Independent Verification Validation (IVV) Program has been enhanced with an FM Technical Reference (TR) suite. Benefits are aimed beyond the IVV community to those that seek ways to efficiently and effectively provide software assurance to reduce the FM risk posture of NASA and other space missions. The identification of particular FM architectures, visibility, and associated IVV techniques provides a TR suite that enables greater assurance that critical software systems will adequately protect against faults and respond to adverse conditions. The role FM has with regard to overall asset protection of flight software systems is being addressed with the development of an adverse condition (AC) database encompassing flight software vulnerabilities.Identification of potential off-nominal conditions and analysis to determine how a system responds to these conditions are important aspects of hazard analysis and fault management. Understanding what ACs the mission may face, and ensuring they are prevented or addressed is the responsibility of the assurance team, which necessarily should have insight into ACs beyond those defined by the project itself. Research efforts sponsored by NASAs Office of Safety and Mission Assurance defined terminology, categorized data fields, and designed a baseline repository that centralizes and compiles a comprehensive listing of ACs and correlated data relevant across many NASA missions. This prototype tool helps projects improve analysis by tracking ACs, and allowing queries based on project, mission type, domain component, causal fault, and other key characteristics. The repository has a firm structure, initial collection of data, and an interface established for informational queries, with plans for integration within the Enterprise Architecture at NASA IVV, enabling support and accessibility across the Agency. The development of an improved workflow process for adaptive, risk-informed FM assurance is currently underway.

Software Verification & Validation↗

Risk-Significant Adverse Condition Awareness Strengthens Assurance of Fault Management Systems

As spaceflight systems increase in complexity, Fault Management (FM) systems are ranked high in risk-based assessment of software criticality, emphasizing the importance of establishing highly competent domain expertise to provide assurance. Adverse conditions (ACs) and specific vulnerabilities encountered by safety- and mission-critical software systems have been identified through efforts to reduce the risk posture of software-intensive NASA missions. Acknowledgement of potential off-nominal conditions and analysis to determine software system resiliency are important aspects of hazard analysis and FM. A key component of assuring FM is an assessment of how well software addresses susceptibility to failure through consideration of ACs. Focus on significant risk predicted through experienced analysis conducted at the NASA Independent Verification & Validation (IV&V) Program enables the scoping of effective assurance strategies with regard to overall asset protection of complex spaceflight as well as ground systems. Research efforts sponsored by NASAs Office of Safety and Mission Assurance (OSMA) defined terminology, categorized data fields, and designed a baseline repository that centralizes and compiles a comprehensive listing of ACs and correlated data relevant across many NASA missions. This prototype tool helps projects improve analysis by tracking ACs and allowing queries based on project, mission type, domain/component, causal fault, and other key characteristics. Vulnerability in off-nominal situations, architectural design weaknesses, and unexpected or undesirable system behaviors in reaction to faults are curtailed with the awareness of ACs and risk-significant scenarios modeled for analysts through this database. Integration within the Enterprise Architecture at NASA IV&V enables interfacing with other tools and datasets, technical support, and accessibility across the Agency. This paper discusses the development of an improved workflow process utilizing this database for adaptive, risk-informed FM assurance that critical software systems will safely and securely protect against faults and respond to ACs in order to achieve successful missions.

IV&V↗

Mission planning and scheduling concept for the Advanced X-ray Astrophysics Facility (AXAF)

Projected for launch in the latter part of 1998, the Advanced X-ray Astrophysics Facility (AXAF), the third satellite in the Great Observatory series, promises to dramatically open the x-ray sky as the Hubble and Compton observatories have done in their respective realms. Unlike its companions, however, AXAF will be placed in a high altitude, highly elliptical orbit (10,000 x 100,000 km), and will therefore be subject to its own unique environment, spacecraft and science instrument constraints and communication network interactions. In support of this mission, ground operations personnel have embarked on the development of the AXAF Offline System (OFLS), a body of software divided into four basic functional elements: (1) Mission Planning and Scheduling, (2) Command Management, (3) Altitude Determination and Sensor Calibration and (4) Spacecraft Support and Engineering Analysis. This paper presents an overview concept for one of these major elements, the Mission Planning and Scheduling subsystem (MPS). The derivation of this concept is described in terms of requirements driven by spacecraft and science instrument characteristics, orbital environment and ground system capabilities. The flowdown of these requirements through the systems analysis process and the definition of MPS interfaces has resulted in the modular grouping of functional subelements depicted in the design implementation approach. The rationale for this design solution is explained and capabilities for the initial prototype system are proposed from the user perspective.

Newhouse, M.↗

Programs Automate Complex Operations Monitoring

Kennedy Space Center, just off the east coast of Florida on Merritt Island, has been the starting place of every human space flight in NASA s history. It is where the first Americans left Earth during Project Mercury, the terrestrial departure point of the lunar-bound Apollo astronauts, as well as the last solid ground many astronauts step foot on before beginning their long stays aboard the International Space Station. It will also be the starting point for future NASA missions to the Moon and Mars and temporary host of the new Ares series rockets designed to take us there. Since the first days of the early NASA missions, in order to keep up with the demands of the intricate and critical Space Program, the launch complex - host to the large Vehicle Assembly Building, two launch pads, and myriad support facilities - has grown increasingly complex to accommodate the sophisticated technologies needed to manage today s space missions. To handle the complicated launch coordination safely, NASA found ways to automate mission-critical applications, resulting in streamlined decision-making. One of these methods, management software called the Control Monitor Unit (CMU), created in conjunction with McDonnell Douglas Space & Defense Systems, has since left NASA, and is finding its way into additional applications.

Source record↗

BioSentinel: Leading the Way for Deep Space CubeSat Missions

Flagship science missions are not alone in Deep Space thanks to BioSentinel, a 6U spacecraft launched on Artemis-1. BioSentinel is one of the longest operating CubeSats beyond cislunar space. The subsystems and COTS components of the BioSentinel bus are a template for future deep space missions, and the lessons learned from over a year of operations will enable improved performance for the next missions. BioSentinel achieved its unprecedented performance for an SLS secondary payload due to preparation, planning, and a robust design. Pre-launch antenna and interface testing with both DSN and ESA confirmed command and data pathways and allowed for operational flexibility in the critical early hours post-deployment. Mission Operations simulations prior to launch identified potential risks and primed operators to respond in flight, preparing the team to react quickly to successfully detumble the spacecraft and enter a power-positive state. The spacecraft would not have survived without the inclusion of the trailblazing 3D-printed composite cold gas propulsion system. The non-standard tank geometry enabled efficient use of the limited space available in the CubeSat, as well as the capability to detumble the spacecraft and manage momentum, while providing sufficient margin to execute potential delta-V maneuvers. The Iris radio has operated for over 18 months with no significant issues. Initial Iris performance estimates have been accurate throughout the mission. BioSentinel continues to collect data on thermal conditions and to validate our performance models with real-world knowledge. We have received exemplary support from our DSN partners. Following the conclusion of the primary science mission, the Linear Energy Transfer (LET) Spectrometer continued to collect solar and galactic radiation data from its location in heliocentric orbit. The free space dataset offered by the BioSentinel LET is a valuable source of data for model validation and future mission planning. As the spacecraft travels farther from Earth it is poised to provide longitudinally distributed measurements of solar particle events during solar maximum. The lessons learned from BioSentinel suggest key areas to enhance performance. The ability to upload modified flight software can increase the stability of memory management. Additional heaters in the propulsion system design have already proven successful on the Starling mission. Streamlining mission operations can reduce costs, increase data return, and better utilize DSN time. Enhancements such as these will facilitate reliable, long-duration deep space exploration using the proven BioSentinel 6U CubeSat bus.

BioSentinel↗

Obtaining the Greatest Scientific Benefit from Observational Platforms by Consideration of the Relative Benefit of Observations

One of the current trends in spacecraft software design is to increase the autonomy of onboard flight and science software. This is especially true when real-time observations may affect the observation schedule of a mission. For many science missions, such as those conducted by the Swift Burst Alert Telescope, the ability of the spacecraft to autonomously respond in real-time to unpredicted science events is crucial for mission success. We apply utility theory within resource management middleware to optimize the real-time performance of application software and achieve maximum system level benefit. We then explore how this methodology can be extended to manage both software and observational resources onboard a spacecraft to achieve the best possible observations.

Chelberg, David↗

Utilizing the ISS Mission as a Testbed to Develop Cognitive Communications Systems

The ISS provides an excellent opportunity for pioneering artificial intelligence software to meet the challenges of real-time communications (comm) link management. This opportunity empowers the ISS Program to forge a testbed for developing cognitive communications systems for the benefit of the ISS mission, manned Low Earth Orbit (LEO) science programs and future planetary exploration programs. In November, 1998, the Flight Operations Directorate (FOD) started the ISS Antenna Manager (IAM) project to develop a single processor supporting multiple comm satellite tracking for two different antenna systems. Further, the processor was developed to be highly adaptable as it supported the ISS mission through all assembly stages. The ISS mission mandated communications specialists with complete knowledge of when the ISS was about to lose or gain comm link service. The current specialty mandated cognizance of large sun-tracking solar arrays and thermal management panels in addition to the highly-dynamic satellite service schedules and rise/set tables. This mission requirement makes the ISS the ideal communications management analogue for future LEO space station and long-duration planetary exploration missions. Future missions, with their precision-pointed, dynamic, laser-based comm links, require complete autonomy for managing high-data rate communications systems. Development of cognitive communications management systems that permit any crew member or payload science specialist, regardless of experience level, to control communications is one of the greater benefits the ISS can offer new space exploration programs. The IAM project met a new mission requirement never previously levied against US space-born communications systems management: process and display the orientation of large solar arrays and thermal control panels based on real-time joint angle telemetry. However, IAM leaves the actual communications availability assessment to human judgment, which introduces unwanted variability because each specialist has a different core of experience with comm link performance. Because the ISS utilizes two different frequency bands, dynamic structure can be occasionally translucent at one frequency while it can completely interdict service at the other frequency. The impact of articulating structure on the comm link can depend on its orientation at the time it impinges on the link. It can become easy for a human specialist to cross-associate experience at one frequency with experience at the other frequency. Additionally, the specialist's experience is incremental, occurring one nine-hour shift at a time. Only the IAM processor experiences the complete 24x7x365 communications link performance for both communications links but, it has no "learning capability." If the IAM processor could be endowed with a cognitive ability to remember past structure-induced comm link outages, based on its knowledge of the ISS position, attitude, communications gear, array joint angles and tracking accuracy, it could convey such experience to the human operator. It could also use its learned communications link behaviors to accurately convey the availability of future communications sessions. Further, the tool could remember how accurately or inaccurately it predicted availability and correct future predictions based on past performance. The IAM tool could learn frequency-specific impacts due to spacecraft structures and pass that information along as "experience." Such development would provide a single artificial intelligence processor that could provide two different experience bases. If it also "knew" the satellite service schedule, it could distinguish structure blockage from schedule or planet blockage and then quickly switch to another satellite. Alternatively, just as a human operator could judge, a cognizant comm system based on the IAM model could "know" that the blockage is not going to last very long and continue tracking a comm satellite, waiting for it to track away from structure. Ultimately, once this capability was fully developed and tested in the Mission Control Center, it could be transferred on-orbit to support development of operations concepts that include more advanced cognitive communications systems. Future applications of this capability are easily foreseen because even more dynamic satellite constellations with more nodes and greater capability are coming. Currently, the ISS fully employs a 300 million bit-per-second (Mbps) return link for harvesting payload science. In the coming eighteen months, it will step up to 600 Mbps. Already there is talk of a 1.2 billion bit-per-second (Gbps) upgrade for the ISS and laser comm links have already been tested from the ISS. Every data rate upgrade mandates more complicated and sensitive communications equipment which implies greater expertise invested in the human operator. Future on-orbit cognizant comm systems will be needed to meet greater performance demands aboard larger, far more complicated spacecraft. In the LEO environment, the old-style one-satellite-per-spacecraft operations concept will give way to a new concept of a single customer spacecraft simultaneously using multiple comm satellites. Much more highly-dynamic manned LEO missions with decades of crew members potentially increase the demand for communications link performance. A cognizant on-board communications system will meet advanced communications demands from future LEO missions and future planetary missions. The ISS has fledgling components of future exploration programs, both LEO and planetary. Further, the Flight Operations Directorate, through the IAM project, has already begun to develop a communications management system that attempts to solve advanced problems ideally represented by dynamic structure impacting scheduled satellite service. With an earnest project to integrate artificial intelligence into the IAM processor, the ISS Program could develop a cognizant communications system that could be adapted and transferred to future on-orbit avionics designs.

Jackson, Dan↗

Utilizing the ISS Mission as a Testbed to Develop Cognitive Communications Systems

The ISS provides an excellent opportunity for pioneering artificial intelligence software to meet the challenges of real-time communications (comm) link management. This opportunity empowers the ISS Program to forge a testbed for developing cognitive communications systems for the benefit of the ISS mission, manned Low Earth Orbit (LEO) science programs and future planetary exploration programs. In November, 1998, the Flight Operations Directorate (FOD) started the ISS Antenna Manager (IAM) project to develop a single processor supporting multiple comm satellite tracking for two different antenna systems. Further, the processor was developed to be highly adaptable as it supported the ISS mission through all assembly stages. The ISS mission mandated communications specialists with complete knowledge of when the ISS was about to lose or gain comm link service. The current specialty mandated cognizance of large sun-tracking solar arrays and thermal management panels in addition to the highly-dynamic satellite service schedules and rise/set tables. This mission requirement makes the ISS the ideal communications management analogue for future LEO space station and long-duration planetary exploration missions. Future missions, with their precision-pointed, dynamic, laser-based comm links, require complete autonomy for managing high-data rate communications systems. Development of cognitive communications management systems that permit any crew member or payload science specialist, regardless of experience level, to control communications is one of the greater benefits the ISS can offer new space exploration programs. The IAM project met a new mission requirement never previously levied against US space-born communications systems management: process and display the orientation of large solar arrays and thermal control panels based on real-time joint angle telemetry. However, IAM leaves the actual communications availability assessment to human judgement, which introduces unwanted variability because each specialist has a different core of experience with comm link performance. Because the ISS utilizes two different frequency bands, dynamic structure can be occasionally translucent at one frequency while it can completely interdict service at the other frequency. The impact of articulating structure on the comm link can depend on its orientation at the time it impinges on the link. It can become easy for a human specialist to cross-associate experience at one frequency with experience at the other frequency. Additionally, the specialist's experience is incremental, occurring one nine-hour shift at a time. Only the IAM processor experiences the complete 24x7x365 communications link performance for both communications links but, it has no "learning capability." If the IAM processor could be endowed with a cognitive ability to remember past structure-induced comm link outages, based on its knowledge of the ISS position, attitude, communications gear, array joint angles and tracking accuracy, it could convey such experience to the human operator. It could also use its learned communications link behaviors to accurately convey the availability of future communications sessions. Further, the tool could remember how accurately or inaccurately it predicted availability and correct future predictions based on past performance. The IAM tool could learn frequency-specific impacts due to spacecraft structures and pass that information along as "experience." Such development would provide a single artificial intelligence processor that could provide two different experience bases. If it also "knew" the satellite service schedule, it could distinguish structure blockage from schedule or planet blockage and then quickly switch to another satellite. Alternatively, just as a human operator could judge, a cognizant comm system based on the IAM model could "know" that the blockage is not going to last very long and continue tracking a comm satellite, waiting for it to track away from structure. Ultimately, once this capability was fully developed and tested in the Mission Control Center, it could be transferred on-orbit to support development of operations concepts that include more advanced cognitive communications systems. Future applications of this capability are easily foreseen because even more dynamic satellite constellations with more nodes and greater capability are coming. Currently, the ISS fully employs its high-data-rate return link for harvesting payload science. In the coming months, it will double that data rate and is forecast to fully utilize that capability. Already there is talk of an upgrade that quadruples the current data rate allocated to ISS payload science before the end of its mission and laser comm links have already been tested from the ISS. Every data rate upgrade mandates more complicated and sensitive communications equipment which implies greater expertise invested in the human operator. Future on-orbit cognizant comm systems will be needed to meet greater performance demands aboard larger, far more complicated spacecraft. In the LEO environment, the old-style one-satellite-per-spacecraft operations concept will give way to a new concept of a single customer spacecraft simultaneously using multiple comm satellites. Much more highly-dynamic manned LEO missions with decades of crew members potentially increase the demand for communications link performance. A cognizant on-board communications system will meet advanced communications demands from future LEO missions and future planetary missions. The ISS has fledgling components of future exploration programs, both LEO and planetary. Further, the Flight Operations Directorate, through the IAM project, has already begun to develop a communications management system that attempts to solve advanced problems ideally represented by dynamic structure impacting scheduled satellite service. With an earnest project to integrate artificial intelligence into the IAM processor, the ISS Program could develop a cognizant communications system that could be adapted and transferred to future on-orbit avionics designs.

Jackson, Dan↗

Marshall Space Flight Center Ground Systems Development and Integration

Ground Systems Development and Integration performs a variety of tasks in support of the Mission Operations Laboratory (MOL) and other Center and Agency projects. These tasks include various systems engineering processes such as performing system requirements development, system architecture design, integration, verification and validation, software development, and sustaining engineering of mission operations systems that has evolved the Huntsville Operations Support Center (HOSC) into a leader in remote operations for current and future NASA space projects. The group is also responsible for developing and managing telemetry and command configuration and calibration databases. Personnel are responsible for maintaining and enhancing their disciplinary skills in the areas of project management, software engineering, software development, software process improvement, telecommunications, networking, and systems management. Domain expertise in the ground systems area is also maintained and includes detailed proficiency in the areas of real-time telemetry systems, command systems, voice, video, data networks, and mission planning systems.

Wade, Gina↗

National Aeronautics and Space Administration Manned Spacecraft Center data base requirements study

A study was conducted to evaluate the types of data that the Manned Spacecraft Center (MSC) should automate in order to make available essential management and technical information to support MSC's various functions and missions. In addition, the software and hardware capabilities to best handle the storage and retrieval of this data were analyzed. Based on the results of this study, recommendations are presented for a unified data base that provides a cost effective solution to MSC's data automation requirements. The recommendations are projected through a time frame that includes the earth orbit space station.

Source record↗

Life Cycle Cost Growth Study for the Discovery and New Frontiers Program Office

The D&NF Program Office LCC Management Study provides a detailed look at the drivers underlying cost overruns and schedule delays for five D&NF missions. While none of the findings are new, the study underlines the importance of continued emphasis on sound project management techniques: a clean project management structure with a clear definition of roles and responsibilities across the various partners in a project, an understanding of institutional standards and procedures and any differences among the partners, and the critical need for a comprehensive IMS that can be used easily and routinely to identify potential threats to the critical path. The study also highlights the continuing need for realistic estimates of the total LCC. Sufficient time and resources must be allocated early in a project to ensure that the appropriate trade studies and analyses are performed across all aspects of a mission: spacecraft, ground system, operations concept, and fault management, to ensure that proposed and confirmed costs truly reflect the resource requirements over the entire mission life cycle. These studies need to include a realistic review of the assumptions underlying the use of new technologies, the integration of heritage and new hardware and software into the total mission environment, and any development and test savings based on heritage technology and lessons learned. Finally, the LCC Management Study stresses the need to listen to, carefully consider, and take positive action regarding the issues raised during reviews by the expert review teams.

Barley, Bryan↗

LST data management and mission operations concept

A candidate design concept for an LST ground facility is described. The design objectives were to use NASA institutional hardware, software and facilities wherever practical, and to maximize efficiency of telescope use. The pointing control performance requirements of LST are summarized, and the major data interfaces of the candidate ground system are diagrammed.

Walker, R.↗

Status of tethered satellite system (TSS) development

The Tethered Satellite System (TSS) is a cooperative space system and science development activity being carried out by the U.S. and Italy. The TSS will involve an instrument-laden satellite that can be deployed from the cargo bay of the Shuttle Orbiter using a long tether to altitudes both above and below that of the Orbiter. This paper discusses the predevelopment activities, development approach and management relationships, current hardware and software designs and interfaces, overall science experiment status and plans, and mission operation planning for the first TSS mission.

Laue, Jay H.↗