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 361 records · Page 20
All sourcesNASA NTRSDOE OSTI
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↗
DOE OSTI2024

NSTXU Diagnostic Disruption Dynamic Loading Represented by Response Spectra

This article presents the results of transient dynamic simulations of loads due to disruption eddy currents on the NSTXU vacuum vessel. Dynamic loading at diagnostic mounting locations is expressed as response spectra derived from the time history results of the dynamic structural simulations of a variety of disruption scenarios. The disruption simulations draw on a history of the project assessments of worst case disruptions for specific components. Major efforts to assess disruption loading have included the vacuum vessel which is the major structural support for the machine, as well as the passive plates (PPs), high harmonic fast wave (HHFW) antenna, and centerstack casing. Each one of these efforts included transient electromagnetic simulations producing time-dependent eddy current Lorentz loads (and in some cases halo loads) which then were applied to time-dependent structural dynamic analyses intended to obtain the proper dynamic amplification factors. In some instances, the EM model and structural model were identical allowing direct transfer of EM forces to the structural model. In other cases, the EM and structural model were not identical and the vector potential (VP) transfer method was used. The results files from these analyses were available (or re-run) to post process in ANSYS Classic time history postprocessor. In conclusion, the ANSYS command is used to create response spectra from time history data at desired points on the vessel.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗
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↗
NASA NTRS2004

Impact of Operating Context on the Use of Structure in Air Traffic Controller Cognitive Processes

This paper investigates the influence of structure on air traffic controllers cognitive processes in the TRACON, En Route, and Oceanic environments. Radar data and voice command analyses were conducted to support hypotheses generated through observations and interviews conducted at the various facilities. Three general types of structure-based abstractions (standard flows, groupings, and critical points) have been identified as being used in each context, though the details of their application varied in accordance with the constraints of the particular operational environment. Projection emerged as a key cognitive process aided by the structure-based abstractions, and there appears to be a significant difference between how time-based versus spatial-based projection is performed by controllers. It is recommended that consideration be given to the value provided by the structure-based abstractions to the controller as well as to maintain consistency between the type (time or spatial) of information support provided to the controller.

Davison, Hayley J.↗
NASA NTRS2014

Virtualization - A Key Cost Saver in NASA Multi-Mission Ground System Architecture

With science team budgets being slashed, and a lack of adequate facilities for science payload teams to operate their instruments, there is a strong need for innovative new ground systems that are able to provide necessary levels of capability processing power, system availability and redundancy while maintaining a small footprint in terms of physical space, power utilization and cooling.The ground system architecture being presented is based off of heritage from several other projects currently in development or operations at Goddard, but was designed and built specifically to meet the needs of the Science and Planetary Operations Control Center (SPOCC) as a low-cost payload command, control, planning and analysis operations center. However, this SPOCC architecture was designed to be generic enough to be re-used partially or in whole by other labs and missions (since its inception that has already happened in several cases!)The SPOCC architecture leverages a highly available VMware-based virtualization cluster with shared SAS Direct-Attached Storage (DAS) to provide an extremely high-performing, low-power-utilization and small-footprint compute environment that provides Virtual Machine resources shared among the various tenant missions in the SPOCC. The storage is also expandable, allowing future missions to chain up to 7 additional 2U chassis of storage at an extremely competitive cost if they require additional archive or virtual machine storage space.The software architecture provides a fully-redundant GMSEC-based message bus architecture based on the ActiveMQ middleware to track all health and safety status within the SPOCC ground system. All virtual machines utilize the GMSEC system agents to report system host health over the GMSEC bus, and spacecraft payload health is monitored using the Hammers Integrated Test and Operations System (ITOS) Galaxy Telemetry and Command (TC) system, which performs near-real-time limit checking and data processing on the downlinked data stream and injects messages into the GMSEC bus that are monitored to automatically page the on-call operator or Systems Administrator (SA) when an off-nominal condition is detected. This architecture, like the LTSP thin clients, are shared across all tenant missions.Other required IT security controls are implemented at the ground system level, including physical access controls, logical system-level authentication authorization management, auditing and reporting, network management and a NIST 800-53 FISMA-Moderate IT Security plan Risk Assessment Contingency Plan, helping multiple missions share the cost of compliance with agency-mandated directives.The SPOCC architecture provides science payload control centers and backup mission operations centers with a cost-effective, standardized approach to virtualizing and monitoring resources that were traditionally multiple racks full of physical machines. The increased agility in deploying new virtual systems and thin client workstations can provide significant savings in personnel costs for maintaining the ground system. The cost savings in procurement, power, rack footprint and cooling as well as the shared multi-mission design greatly reduces upfront cost for missions moving into the facility. Overall, the authors hope that this architecture will become a model for how future NASA operations centers are constructed!

Ground System Architecture↗
NASA NTRS1971

A real time programmable data compression system for video data.

Description of the implementation of a data compression system for the real-time operational transmission (through microwave links) of ATS satellite pictures between the command and data acquisition station and a central location for computer processing. The system features the use of general-purpose minicomputers for encoding and decoding; this makes it possible to vary the employed data compression technique and to make simultaneous statistical calculations on the data. Data compression and expansion is accomplished in a manner that does not lower data quality.

Kutz, R. L.↗
NASA NTRS1974

MSFC Skylab instrumentation and communication system mission evaluation

An evaluation of the in-orbit performance of the instrumentation and communications systems installed on Skylab is presented. Performance is compared with functional requirements and the fidelity of communications. In-orbit performance includes processing engineering, scientific, experiment, and biomedical data, implementing ground-generated commands, audio and video communication, generating rendezvous ranging information, and radio frequency transmission and reception. A history of the system evolution based on the functional requirements and a physical description of the launch configuration is included. The report affirms that the instrumentation and communication system satisfied all imposed requirements.

Adair, B. M.↗
NASA NTRS1980

Application of a microprocessor to a spacecraft attitude control

The attitude control system (ACS) microprocessor development work spanned three main design areas: hardware and instruction set, ACS firmware, and hardware firmware verification testing. The processor hardware utilizes two parallel 4 bit microprocessors. The firmware includes data processing for five sensors, four attitude control laws, and telemetry and commands.

Brady, D. H.↗
NASA NTRS1980

Shuttle mission simulator

The simulator was designed to provide real time simulation capability for all phases of the Shuttle Transportation System orbital missions including prelaunch, ascent, onorbit operations, deorbit, entry, approach/landing, and rollout. Full mission continuity is provided in transition between these mission phases. Dual fixed and motion base crew stations, instructor/operator stations, and computer systems allow parallel, simultaneous crew training with either complex capable of being individually integrated with the mission control center. This integrated training capability allows flight control personnel training in the air/ground interface areas of tracking, telemetry (vehicle systems monitoring), uplink command control, and communications. With the exception of the simulated Data Processing System, which utilizes actual flight computers and associated flight software, all orbiter onboard systems are functionally simulated with extensive simulated malfunction capabilities. Additionally, crew out-the-window visual scenes, and aural cues are rigorously simulated.

Olasky, C.↗
NASA NTRS1991

Docking System With Video Feedback

Video-sensor/electronic-feedback control system being developed to provide automatic control of final stage of approach of active vehicle to passive vehicle or object. No communication between vehicles necessary. Docking target, mounted on post on passive vehicle, has three reflective dots, positions of which measured in image to determine relative position and orientation of target and vehicle. Control channels process video-sensor feedback into motion-control signals (thrustor commands in spacecraft or motor commands in robot). Conceived for use aboard chasing spacecraft to control its maneuvers in docking with chased spacecraft, concept also useful in controlling coupling of aircraft in flight or vessels on water or in controlling approach of robot to object to be manipulated.

Dabrey, Richard↗
NASA NTRS1991

Experimental testbed for cooperative robotic manipulators

The robotic testbed facility within Rensselaer's Center for Intelligent Robotic Systems for Space Exploration consists of two PUMA robot manipulators, each mounted on a moving platform. Each platform has a tilt and rotate capability and can move along a two rail linear track. One purpose of this system is to demonstrate the coordination of two arms in relative motion to each other. The system is also useful for investigating the integration problems that occur in an environment that is heavily dependent upon the acquisition, transmission, and processing of data in the form of information, knowledge, and control commands.

Desrochers, A.↗
NASA NTRS1992

A stochastic optimal feedforward and feedback control methodology for superagility

A new control design methodology is developed: Stochastic Optimal Feedforward and Feedback Technology (SOFFT). Traditional design techniques optimize a single cost function (which expresses the design objectives) to obtain both the feedforward and feedback control laws. This approach places conflicting demands on the control law such as fast tracking versus noise atttenuation/disturbance rejection. In the SOFFT approach, two cost functions are defined. The feedforward control law is designed to optimize one cost function, the feedback optimizes the other. By separating the design objectives and decoupling the feedforward and feedback design processes, both objectives can be achieved fully. A new measure of command tracking performance, Z-plots, is also developed. By analyzing these plots at off-nominal conditions, the sensitivity or robustness of the system in tracking commands can be predicted. Z-plots provide an important tool for designing robust control systems. The Variable-Gain SOFFT methodology was used to design a flight control system for the F/A-18 aircraft. It is shown that SOFFT can be used to expand the operating regime and provide greater performance (flying/handling qualities) throughout the extended flight regime. This work was performed under the NASA SBIR program. ICS plans to market the software developed as a new module in its commercial CACSD software package: ACET.

Halyo, Nesim↗