Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 343 records · Page 19
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Spitzer Space Telescope Sequencing Operations Software, Strategies, and Lessons Learned

The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.

missions operations↗
NASA NTRS2011

Space Shuttle Day-of-Launch Trajectory Design Operations

A top priority of any launch vehicle is to insert as much mass into the desired orbit as possible. This requirement must be traded against vehicle capability in terms of dynamic control, thermal constraints, and structural margins. The vehicle is certified to specific structural limits which will yield certain performance characteristics of mass to orbit. Some limits cannot be certified generically and must be checked with each mission design. The most sensitive limits require an assessment on the day-of-launch. To further minimize vehicle loads while maximizing vehicle performance, a day-of-launch trajectory can be designed. This design is optimized according to that day s wind and atmospheric conditions, which increase the probability of launch. The day-of-launch trajectory design and verification process is critical to the vehicle s safety. The Day-Of-Launch I-Load Update (DOLILU) is the process by which the National Aeronautics and Space Administration's (NASA) Space Shuttle Program tailors the vehicle steering commands to fit that day s environmental conditions and then rigorously verifies the integrated vehicle trajectory s loads, controls, and performance. This process has been successfully used for almost twenty years and shares many of the same elements with other launch vehicles that execute a day-of-launch trajectory design or day-of-launch trajectory verification. Weather balloon data is gathered at the launch site and transmitted to the Johnson Space Center s Mission Control. The vehicle s first stage trajectory is then adjusted to the measured wind and atmosphere data. The resultant trajectory must satisfy loads and controls constraints. Additionally, these assessments statistically protect for non-observed dispersions. One such dispersion is the change in the wind from the last measured balloon to launch time. This process is started in the hours before launch and is repeated several times as the launch count proceeds. Should the trajectory design not meet all constraint criteria, Shuttle would be No-Go for launch. This Shuttle methodology is very similar to other unmanned launch vehicles. By extension, this method would likely be employed for any future NASA launch vehicle. This paper will review the Shuttle s day-of-launch trajectory optimization and verification operations as an example of a more generic application of day-of-launch design and validation. With Shuttle s retirement, it is fitting to document the current state of this critical process and capture lessons learned to benefit current and future launch vehicle endeavors.

Harrington, Brian E.↗
NASA NTRS1981

Integrated command, control, communications and computation system functional architecture

The functional architecture for an integrated command, control, communications, and computation system applicable to the command and control portion of the NASA End-to-End Data. System is described including the downlink data processing and analysis functions required to support the uplink processes. The functional architecture is composed of four elements: (1) the functional hierarchy which provides the decomposition and allocation of the command and control functions to the system elements; (2) the key system features which summarize the major system capabilities; (3) the operational activity threads which illustrate the interrelationahip between the system elements; and (4) the interfaces which illustrate those elements that originate or generate data and those elements that use the data. The interfaces also provide a description of the data and the data utilization and access techniques.

Cooley, C. G.↗
NASA NTRS1972

Observations and impressions from lunar orbit

On Apollo 16, the command module pilot made observations of particular surface features and processes to complement photographic and other remotely sensed data. Emphasis was placed on geological problems that required the extreme dynamic range and color sensitivities of the human eye; repetitive observations of varying sun angles and viewing directions; and, in some cases, on-the-scene interpretations. Visual observations and impressions recorded during the mission verified the effectiveness of the hardware and techniques used. The orbiting observer functioned both as a sensor, in otherwise inaccessible areas such as earthshine and shadows, and as a designator of potentially significant data that were acquired on the photographic record.

Mattingly, T. K.↗
NASA NTRS1981

On-line structural parameter identification

Algorithms are presented for on-line parameter identification of structural dynamic systems. As an example, they are used to calculate the parameters of a modal model of a flexible beam. The algorithms are tested using hardware consisting of a 12 ft. beam with four voice coil actuators and nine noncontacting displacement sensors. They are programmed in a CDC Cyber 175 digital computer which provides input command signals for the actuators, reads the sensor data, and processes the algorithm to calculate consistent estimates of the modal parameters of the beam. Experimental results are compared with those of simulation analysis.

Thau, F. E.↗
NASA NTRS1990

BUBBLES: an Automated Decision Support System for Final Approach Controllers

With the assumptions that an explicit schedule exists for landings (and takeoffs) at each runway, that each aircraft has declared an IAS for final approach and will be obligated to fly it as accurately as possible, and that there is a continuous estimate of average windspeed on approach, the objective was to provide automated cues to assist controllers in the spacing of landing aircraft. The cues have two characteristics. First, they are adaptive to estimation errors in position and speed by the radar tracking process and piloting errors in the execution of turns and commanded speed reductions. Second, the cues are responsive to the desires of the human controller. Several diagrams are used to help explain the system.

Chi, Zhizang↗
NASA NTRS1991

Network interface unit design options performance analysis

An analysis is presented of three design options for the Space Station Freedom (SSF) onboard Data Management System (DMS) Network Interface Unit (NIU). The NIU provides the interface from the Fiber Distributed Data Interface (FDDI) local area network (LAN) to the DMS processing elements. The FDDI LAN provides the primary means for command and control and low and medium rate telemetry data transfers on board the SSF. The results of this analysis provide the basis for the implementation of the NIU.

Miller, Frank W.↗
NASA NTRS1992

Design and performance comparison of fuzzy logic based tracking controllers

Several camera tracking controllers based on fuzzy logic principles have been designed and tested in software simulation in the software technology branch at the Johnson Space Center. The fuzzy logic based controllers utilize range measurement and pixel positions from the image as input parameters and provide pan and tilt gimble rate commands as output. Two designs of the rulebase and tuning process applied to the membership functions are discussed in light of optimizing performance. Seven test cases have been designed to test the performance of the controllers for proximity operations where approaches like v-bar, fly-around and station keeping are performed. The controllers are compared in terms of responsiveness, and ability to maintain the object in the field-of-view of the camera. Advantages of the fuzzy logic approach with respect to the conventional approach have been discussed in terms of simplicity and robustness.

Lea, Robert N.↗
NASA NTRS2003

The X-38 Spacecraft Fault-Tolerant Avionics System

In 1995 NASA began an experimental program to develop a reusable crew return vehicle (CRV) for the International Space Station. The purpose of the CRV was threefold: (i) to bring home an injured or ill crewmember; (ii) to bring home the entire crew if the Shuttle fleet was grounded; and (iii) to evacuate the crew in the case of an imminent Station threat (i.e., fire, decompression, etc). Built at the Johnson Space Center, were two approach and landing prototypes and one spacecraft demonstrator (called V201). A series of increasingly complex ground subsystem tests were completed, and eight successful high-altitude drop tests were achieved to prove the design concept. In this program, an unprecedented amount of commercial-off-the-shelf technology was utilized in this first crewed spacecraft NASA has built since the Shuttle program. Unfortunately, in 2002 the program was canceled due to changing Agency priorities. The vehicle was 80% complete and the program was shut down in such a manner as to preserve design, development, test and engineering data. This paper describes the X-38 V201 fault-tolerant avionics system. Based on Draper Laboratory's Byzantine-resilient fault-tolerant parallel processing system and their "network element" hardware, each flight computer exchanges information on a strict timescale to process input data, compare results, and issue voted vehicle output commands. Major accomplishments achieved in this development include: (i) a space qualified two-fault tolerant design using mostly COTS (hardware and operating system); (ii) a single event upset tolerant network element board, (iii) on-the-fly recovery of a failed processor; (iv) use of synched cache; (v) realignment of memory to bring back a failed channel; (vi) flight code automatically generated from the master measurement list; and (vii) built in-house by a team of civil servants and support contractors. This paper will present an overview of the avionics system and the hardware implementation, as well as the system software and vehicle command & telemetry functions. Potential improvements and lessons learned on this program are also discussed.

Kouba,Coy↗
NASA NTRS2004

Framework for Development of Object-Oriented Software

The Real-Time Control (RTC) Application Framework is a high-level software framework written in C++ that supports the rapid design and implementation of object-oriented application programs. This framework provides built-in functionality that solves common software development problems within distributed client-server, multi-threaded, and embedded programming environments. When using the RTC Framework to develop software for a specific domain, designers and implementers can focus entirely on the details of the domain-specific software rather than on creating custom solutions, utilities, and frameworks for the complexities of the programming environment. The RTC Framework was originally developed as part of a Space Shuttle Launch Processing System (LPS) replacement project called Checkout and Launch Control System (CLCS). As a result of the framework s development, CLCS software development time was reduced by 66 percent. The framework is generic enough for developing applications outside of the launch-processing system domain. Other applicable high-level domains include command and control systems and simulation/ training systems.

Perez-Poveda, Gus↗
NASA NTRS2014

Enhanced International Space Station Ku-Band Telemetry Service

The International Space Station (ISS) is in an operational configuration. To fully utilize the ISS and take advantage of the modern protocols and updated Ku-band access, the Huntsville Operations Support Center (HOSC) has designed an approach to extend the Kuband forward link access for payload investigators to their on-orbit payloads. This dramatically increases the ground to ISS communications for those users. This access also enables the ISS flight controllers operating in the Payload Operations and Integration Center to have more direct control over the systems they are responsible for managing and operating. To extend the Ku-band forward link to the payload user community the development of a new command server is necessary. The HOSC subsystems were updated to process the Internet Protocol Encapsulated packets, enable users to use the service based on their approved services, and perform network address translation to insure that the packets are forwarded from the user to the correct payload repeating that process in reverse from ISS to the payload user. This paper presents the architecture, implementation, and lessons learned. This will include the integration of COTS hardware and software as well as how the device is incorporated into the operational mission of the ISS. Thus, this paper also discusses how this technology can be applicable to payload users of the ISS.

Cecil, Andrew J.↗
NASA NTRS2010

MOS 2.0: The Next Generation in Mission Operations Systems

A Mission Operations System (MOS) or Ground System constitutes that portion of an overall space mission Enterprise that resides here on Earth. Over the past two decades, technological innovations in computing and software technologies have allowed an MOS to support ever more complex missions while consuming a decreasing fraction of Project development budgets. Despite (or perhaps, because of) such successes, it is routine to hear concerns about the cost of MOS development. At the same time, demand continues for Ground Systems which will plan more spacecraft activities with fewer commanding errors, provide scientists and engineers with more autonomous functionality, process and manage larger and more complex data more quickly, all while requiring fewer people to develop, deploy, operate and maintain them. One successful approach to such concerns over this period is a multimission approach, based on the reuse of portions (most often software) developed and used in previous missions. The Advanced Multi-Mission Operations System (AMMOS), developed for deep-space science missions, is one successful example of such an approach. Like many computing-intensive systems, it has grown up in a near-organic fashion from a relatively simple set of tools into a complexly interrelated set of capabilities. Such systems, like a city lacking any concept of urban planning, can and will grow in ways that are neither efficient nor particularly easy to sustain. To meet the growing demands and unyielding constraints placed on ground systems, a new approach is necessary. Under the aegis of a multi-year effort to revitalize the AMMOS's multimission operations capabilities, we are utilizing modern practices in systems architecting and model-based engineering to create the next step in Ground Systems: MOS 2.0. In this paper we outline our work (ongoing and planned) to architect and design a multimission MOS 2.0, describe our goals and measureable objectives, and discuss some of the benefits that this top-down, architectural approach holds for creating a more flexible and capable MOS for Missions while holding the line on cost.

ground systems↗
NASA NTRS2008

Preparing Cassini Uplink Operations for Extended Mission

The Cassini-Huygens Mission to Saturn and Titan, a joint venture between the National Aeronautics and Space Administration, the European Space Agency, and the Italian Space Agency, is conducting a four-year, prime mission exploring the Saturnian system, including its atmosphere, rings, magnetosphere, moons and icy satellites. Launched in 1997, Cassini began its prime mission in 2004. Cassini is now preparing for a new era, a two-year extended mission to revisit many of the highlights and new discoveries made during the prime mission. Because of the light time delay from Earth to Saturn, and the time needed to coordinate the complicated science and engineering activities that take place on the spacecraft, commanding on Cassini is done in approximately 40-day intervals known as sequences. The Cassini Uplink Operations team is responsible for the final development and validation of the pointing profile and instrument and spacecraft commands that are contained in a sequence. During this final analysis prior to uplink to the spacecraft, thorough and exact evaluation is necessary to ensure there are no mistakes during commanding. In order to perform this evaluation, complete and refined processes and procedures are fundamental. The Uplink Operations team is also responsible for anomaly response during sequence execution, a process in which critical decisions often are made in real-time. Recent anomalies on other spacecraft missions have highlighted two major risks in the operations process: (1) personnel turnover and the retirement of critical knowledge and (2) aging, outdated operations procedures. If other missions are a good barometer, the Cassini extended mission will be presented with a high personnel turnover of the Cassini flight team, which could lead to a loss of expertise that has been essential to the success of the prime mission. In order to prepare the Cassini Uplink Operations Team for this possibility and to continue to develop and operate safe science and engineering sequences, a review and major update of the current documentation and operations procedures was needed. This paper will address the changes made to extended mission sequence generation processes primarily due to new restrictions in spacecraft operating capability and lessons learned from prime mission. In addition, it will address the state of the prime mission operations procedures, the philosophy changes and updates that were made to those procedures in response to process improvement, and the validation of those new procedures through the training of current and new personnel. And lastly, it will address the lessons learned throughout prime mission and how the Uplink Operations team chose to incorporate those lessons into the working documentation and team knowledge. This incorporation was necessary to facilitate the success of the extended mission with potentially all new personnel at some point prior to the end of the mission.

Maxwell, Jennifer L.↗
NASA NTRS2022

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗
NASA NTRSDate not supplied

System-Theoretic Analysis of Unsafe Collaborative Control in Teaming Systems

The interactions that occur in human-teaming are inspiring novel aerospace designs aimed at improving how humans and machines, or multiple machines, work together. Unfortunately, current Systems Engineering processes are ill-equipped to handle these complex relationships and are unable to design and assure the safety for these systems. To close part of this gap, this paper introduces a novel system-theoretic analytical process to identify unsafe collaborative control actions. It is part of a broader set of techniques that extend the state-of-the-art in hazard analysis, System Theoretic Process Analysis (STPA), to systematically address collaboration. The method rigorously expresses the different ways multiple commands may be unsafe together. Using Systems Theory, it employs abstraction to manage the combinatorial complexity in enumerating control contributions from multiple collaborating components. An algorithm integrates these concepts into an end-to-end process and is supported by automation to enumerate, refine, prune, and prioritize unsafe combinations of control actions. The output of the method feeds the specification of system requirements to implement safety-guided design starting early in concept development. The process is demonstrated on a manned-unmanned aircraft teaming case study and finds new causal factors that were not previously found in a past hazard analysis of the same system.

System Safety↗
NASA NTRS1987

Digital signal processing algorithms for automatic voice recognition

The current digital signal analysis algorithms are investigated that are implemented in automatic voice recognition algorithms. Automatic voice recognition means, the capability of a computer to recognize and interact with verbal commands. The digital signal is focused on, rather than the linguistic, analysis of speech signal. Several digital signal processing algorithms are available for voice recognition. Some of these algorithms are: Linear Predictive Coding (LPC), Short-time Fourier Analysis, and Cepstrum Analysis. Among these algorithms, the LPC is the most widely used. This algorithm has short execution time and do not require large memory storage. However, it has several limitations due to the assumptions used to develop it. The other 2 algorithms are frequency domain algorithms with not many assumptions, but they are not widely implemented or investigated. However, with the recent advances in the digital technology, namely signal processors, these 2 frequency domain algorithms may be investigated in order to implement them in voice recognition. This research is concerned with real time, microprocessor based recognition algorithms.

Botros, Nazeih M.↗
NASA NTRS1992

Running SINDA '85/FLUINT interactive on the VAX

Computer software as engineering tools are typically run in three modes: Batch, Demand, and Interactive. The first two are the most popular in the SINDA world. The third one is not so popular, due probably to the users inaccessibility to the command procedure files for running SINDA '85, or lack of familiarity with the SINDA '85 execution processes (pre-processor, processor, compilation, linking, execution and all of the file assignment, creation, deletions and de-assignments). Interactive is the mode that makes thermal analysis with SINDA '85 a real-time design tool. This paper explains a command procedure sufficient (the minimum modifications required in an existing demand command procedure) to run SINDA '85 on the VAX in an interactive mode. To exercise the procedure a sample problem is presented exemplifying the mode, plus additional programming capabilities available in SINDA '85. Following the same guidelines the process can be extended to other SINDA '85 residence computer platforms.

Simmonds, Boris↗