Search NASA⌕ Search

SEARCH · Search NASA

Results for “messages”

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 73 records · Page 4

A Model-based Approach to Controlling the ST-5 Constellation Lights-Out Using the GMSEC Message Bus and Simulink

Space Technology 5 (ST-5) is a three-satellite constellation, technology validation mission under the New Millennium Program at NASA to be launched in March 2006. One of the key technologies to be validated is a lights-out, model-based operations approach to be used for one week to control the ST-5 constellation with no manual intervention. The ground architecture features the GSFC Mission Services Evolution Center (GMSEC) middleware, which allows easy plugging in of software components and a standardized messaging protocol over a software bus. A predictive modeling tool built on MatLab's Simulink software package makes use of the GMSEC standard messaging protocol to interface to the Advanced Mission Planning System (AMPS) Scenario Scheduler which controls all activities, resource allocation and real-time re-profiling of constellation resources when non-nominal events occur. The key features of this system, which we refer to as the ST-5 Simulink system, are as follows: Original daily plan is checked to make sure that predicted resources needed are available by comparing the plan against the model. As the plan is run in real-time, the system re-profiles future activities in real-time if planned activities do not occur in the predicted timeframe or fashion. Alert messages are sent out on the GMSEC bus by the system if future predicted problems are detected. This will allow the Scenario Scheduler to correct the situation before the problem happens. The predictive model is evolved automatically over time via telemetry updates thus reducing the cost of implementing and maintaining the models by an order of magnitude from previous efforts at GSFC such as the model-based system built for MAP in the mid-1990's. This paper will describe the key features, lessons learned and implications for future missions once this system is successfully validated on-orbit in 2006.

Witt, Kenneth J.↗

MOC Automation with GMSEC and the Generic Extendable Message Utility (GEMU)

Automation has become critical for ground systems, improving efficiency and reliability while reducing costs across mission operations. The Goddard Mission Services Evolution Center (GMSEC) software suite has played a significant role in enabling this automation, leveraging its publish/subscribe paradigm through a message bus architecture to facilitate seamless communication and data flow. Historically, the GMSEC suite, through components like Criteria Action Table (CAT) has been pivotal in automating ground system capabilities. However, as technology advances, limitations in automation with CAT have emerged, creating an opportunity to enhance ground system automation through the introduction of GEMU. This new GMSEC component brings new capabilities and addresses specific automation constraints that CAT could not overcome, allowing for more sophisticated, flexible, and efficient message processing. GEMU, at its core, is designed to accelerate the development of custom GMSEC-compliant applications. It enables users to construct automated message processing pipelines quickly, supporting both drag-and-drop web-based configuration and scripting through a simple domain-specific language. This advancement not only simplifies the process but also reduces the time needed for implementing automated solutions. This presentation will outline GEMU’s potential value in improving mission operations automation. It will highlight the benefits of transitioning from CAT to GEMU and offer insights into how GEMU can drive operational efficiencies. We will also provide an overview of the automation capabilities of GEMU and its potential impact on mission operations centers (MOCs).

GMSEC↗

Asynchronous Message Service for Deep Space Mission Operations

AMS is in early stages of standardization. a) CCSDS "white book" (Proposed Standard) has been published. b) A single implementation has been developed and is being tested. No major obstacles encountered so far. a) Protocol has changed since original concept paper, but not radically. b) Design concepts seem to be sound. AMS capabilities seem to be broadly applicable. a) On-board, proximity, and deep-space communications for spacecraft. b) Suitable underlying messaging protocol for proposed CCSDS Spacecraft Monitor and Control protocols. c) Terrestrial applications designed for operation over a message bus. AMS Working Group within CCSDS is on schedule, so far.

asynchronous message exchanges↗

Space Flight Middleware: Remote AMS over DTN for Delay-Tolerant Messaging

This paper describes a technique for implementing scalable, reliable, multi-source multipoint data distribution in space flight communications -- Delay-Tolerant Reliable Multicast (DTRM) -- that is fully supported by the "Remote AMS" (RAMS) protocol of the Asynchronous Message Service (AMS) proposed for standardization within the Consultative Committee for Space Data Systems (CCSDS). The DTRM architecture enables applications to easily "publish" messages that will be reliably and efficiently delivered to an arbitrary number of "subscribing" applications residing anywhere in the space network, whether in the same subnet or in a subnet on a remote planet or vehicle separated by many light minutes of interplanetary space. The architecture comprises multiple levels of protocol, each included for a specific purpose and allocated specific responsibilities: "application AMS" traffic performs end-system data introduction and delivery subject to access control; underlying "remote AMS" directs this application traffic to populations of recipients at remote locations in a multicast distribution tree, enabling the architecture to scale up to large networks; further underlying Delay-Tolerant Networking (DTN) Bundle Protocol (BP) advances RAMS protocol data units through the distribution tree using delay-tolerant storeand- forward methods; and further underlying reliable "convergence-layer" protocols ensure successful data transfer over each segment of the end-to-end route. The result is scalable, reliable, delay-tolerant multi-source multicast that is largely self-configuring.

Disruption Tolerant Networking (DTN)↗

A message passing kernel for the hypercluster parallel processing test bed

A Message-Passing Kernel (MPK) for the Hypercluster parallel-processing test bed is described. The Hypercluster is being developed at the NASA Lewis Research Center to support investigations of parallel algorithms and architectures for computational fluid and structural mechanics applications. The Hypercluster resembles the hypercube architecture except that each node consists of multiple processors communicating through shared memory. The MPK efficiently routes information through the Hypercluster, using a message-passing protocol when necessary and faster shared-memory communication whenever possible. The MPK also interfaces all of the processors with the Hypercluster operating system (HYCLOPS), which runs on a Front-End Processor (FEP). This approach distributes many of the I/O tasks to the Hypercluster processors and eliminates the need for a separate I/O support program on the FEP.

Blech, Richard A.↗

NCC simulation model. Phase 2: Simulating the operations of the Network Control Center and NCC message manual

The network control center (NCC) provides scheduling, monitoring, and control of services to the NASA space network. The space network provides tracking and data acquisition services to many low-earth orbiting spacecraft. This report describes the second phase in the development of simulation models for the FCC. Phase one concentrated on the computer systems and interconnecting network.Phase two focuses on the implementation of the network message dialogs and the resources controlled by the NCC. Performance measures were developed along with selected indicators of the NCC's operational effectiveness.The NCC performance indicators were defined in terms of the following: (1) transfer rate, (2) network delay, (3) channel establishment time, (4) line turn around time, (5) availability, (6) reliability, (7) accuracy, (8) maintainability, and (9) security. An NCC internal and external message manual is appended to this report.

Benjamin, Norman M.↗

Efficient Tracing for On-the-Fly Space-Time Displays in a Debugger for Message Passing Programs

In this work we describe the implementation of a practical mechanism for collecting and displaying trace information in a debugger for message passing programs. We introduce a trace format that is highly compressible while still providing information adequate for debugging purposes. We make the mechanism convenient for users to access by incorporating the trace collection in a set of wrappers for the MPI (message passing interface) communication library. We implement several debugger operations that use the trace display: consistent stoplines, undo, and rollback. They all are implemented using controlled replay, which executes at full speed in target processes until the appropriate position in the computation is reached. They provide convenient mechanisms for getting to places in the execution where the full power of a state-based debugger can be brought to bear on isolating communication errors.

Hood, Robert↗

Layered virus protection for the operations and administrative messaging system

NASA's Deep Space Network (DSN) is critical in supporting the wide variety of operating and plannedunmanned flight projects. For day-to-day operations it relies on email communication between the three Deep Space Communication Complexes (Canberra, Goldstone, Madrid) and NASA's Jet Propulsion Laboratory. The Operations & Administrative Messaging system, based on the Microsoft Windows NTand Exchange platform, provides the infrastructure that is required for reliable, mission-critical messaging. The reliability of this system, however, is threatened by the proliferation of email viruses that continue to spread at alarming rates. A layered approach to email security has been implemented across the DSN to protect against this threat.

IT security antivirus↗

Verification of Faulty Message Passing Systems with Continuous State Space in PVS

We present a library of Prototype Verification System (PVS) meta-theories that verifies a class of distributed systems in which agent commu nication is through message-passing. The theoretic work, outlined in, consists of iterative schemes for solving systems of linear equations , such as message-passing extensions of the Gauss and Gauss-Seidel me thods. We briefly review that work and discuss the challenges in formally verifying it.

Pilotto, Concetta↗

The Impact of Data Communications Messages in the Terminal Area on Flight Crew Workload and Eye Scanning

This paper, to accompany a discussion panel, describes a collaborative FAA and NASA research study to determine the effect Data Communications (Data Comm) messages have on flight crew workload and eye scanning behavior in busy terminal area operations. In the Next Generation Air Transportation System Concept of Operations, for the period 2017-2022, the FAA envisions Data Comm between controllers and the flight crew to become the primary means of communicating non-time critical information. Four research conditions were defined that span current day to future equipage levels (Voice with Paper map, Data Comm with Paper map, Data Comm with Moving Map Display with ownship position displayed, Data Comm with Moving Map, ownship and taxi route displayed), and were used to create arrival and departure scenarios at Boston Logan Airport. Preliminary results for workload, situation awareness, and pilot head-up time are presented here. Questionnaire data indicated that pilot acceptability, workload, and situation awareness ratings were favorable for all of the conditions tested. Pilots did indicate that there were times during final approach and landing when they would prefer not to hear the message chime, and would not be able to make a quick response due to high priority tasks in the cockpit.

Comstock, James R., Jr.↗

STK Integrated Message Production List Editor (SIMPLE) for CEO Operations

Late in fiscal year 2011, the Crew Earth Observations (CEO) team was tasked to upgrade and replace its mission planning and mission operations software systems, which were developed in the Space Shuttle era of the 1980s and 1990s. The impetuses for this change were the planned transition of all workstations to the Windows 7 64-bit operating system and the desire for more efficient and effective use of Satellite Tool Kit (STK) software required for reliable International Space Station (ISS) Earth location tracking. An additional requirement of this new system was the use of the same SQL database of CEO science sites from the SMMS, which was also being developed. STK Integrated Message Production List Editor (SIMPLE) is the essential, all-in-one tool now used by CEO staff to perform daily ISS mission planning to meet its requirement to acquire astronaut photography of specific sites on Earth. The sites are part of a managed, long-term database that has been defined and developed for scientific, educational, and public interest. SIMPLE's end product is a set of basic time and location data computed for an operator-selected set of targets that the ISS crew will be asked to photograph (photography is typically planned 12 to 36 hours out). The CEO operator uses SIMPLE to (a) specify a payload operations planning period; (b) acquire and validate the best available ephemeris data (vectors) for the ISS during the planning period; (c) ingest and display mission-specific site information from the CEO database; (d) identify and display potential current dynamic event targets as map features; (e) compute and display time and location information for each target; (f) screen and select targets based on known crew availability constraints, obliquity constraints, and real-time evaluated constraints to target visibility due to illumination (sun elevation) and atmospheric conditions (weather); and finally (g) incorporate basic, computed time and location information for each selected target into the daily CEO Target List product (message) for submission to ISS payload planning and integration teams for their review and approval prior to uplink. SIMPLE requires and uses the following resources: an ISS mission planning period Greenwich Mean Time start date/time and end date/time), the best available ISS mission ephemeris data (vectors) for that planning period, the STK software package configured for the ISS, and an ISS mission-specific subset of the CEO sites database. The primary advantages realized by the development and implementation of SIMPLE into the CEO payload operations support activity are a smooth transition to the Windows 7 operating system upon scheduled workstation refresh; streamlining of the input and verification of the current ISS ephemeris (vector data); seamless incorporation of selected contents of the SQL database of science sites; the ability to tag and display potential dynamic event opportunities on orbit track maps; simplification of the display and selection of encountered sites based on crew availability, illumination, obliquity, and weather constraints; the incorporation of high-quality mapping of the Earth with various satellite-based datasets for use in describing targets; and the ability to encapsulate and export the essential selected target elements in XML format for use by onboard Earth-location systems, such as Worldmap. SIMPLE is a carefully designed and crafted in-house software package that includes detailed help files for the user and meticulous internal documentation for future modifications. It was delivered in February 2012 for test and evaluation. Following acceptance, it was implemented for CEO mission operations support in May 2012.

Trenchard, Mike↗

Cockpit Interfaces, Displays, and Alerting Messages for the Interval Management Alternative Clearances (IMAC) Experiment

This document describes the IM cockpit interfaces, displays, and alerting capabilities that were developed for and used in the IMAC experiment, which was conducted at NASA Langley in the summer of 2015. Specifically, this document includes: (1) screen layouts for each page of the interface; (2) step-by-step instructions for data entry, data verification and input error correction; (3) algorithm state messages and error condition alerting messages; (4) aircraft speed guidance and deviation indications; and (5) graphical display of the spatial relationships between the Ownship aircraft and the Target aircraft. The controller displays for IM will be described in a separate document.

Baxley, Brian T.↗

Message transfer service for space applications

Spacecraft applications that interact with on-board sensors, effectors, and major components have traditionally used private interfaces which are tightly bound to the interface details of the data links connecting these sub-systems. The latest spacecraft, which often include several powerful processors running real time operating systems, high-speed on-board networks, and intelligent peripherals, can support a more layered networked environment. Use of standard interfaces and networked elements is expected to yield reusable software and hardware components. Within CCSDS Panel 1K we have been developing such on-board interface standards. This paper will present a Message Transfer Service that defines a common API for use within a single spacecraft or among spacecraft flying in a constellation.

CCSDS SOIF message service space communication↗

Asynchronous Message Passing in the JPL Flight System Testbed

The flight mission simulation software in the Jet Propulsion Laboratory's Flight System Testbed (FST) is a heterogeneous, distributed system that is built on an interprocess communication model of asynchronous message passing rather than remote procedure calls (RPCs). The reasoning behind this design decision is discussed; the mechanism used to implement it (.

message passing RPC interprocess communication dis↗

Overview of AMS (CCSDS Asynchronous Message Service)

This viewgraph presentation gives an overview of the Consultative Committee for Space Data Systems (CCSDS) Asynchronous Message Service (AMS). The topics include: 1) Key Features; 2) A single AMS continuum; 3) The AMS Protocol Suite; 4) A multi-continuum venture; 5) Constraining transmissions; 6) Security; 7) Fault Tolerance; 8) Performance of Reference Implementation; 9) AMS vs Multicast (1); 10) AMS vs Multicast (2); 11) RAMS testing exercise; and 12) Results.

asynchronous↗

ATD-2 TTP Flight Delay Messages

This document is the third of five documents that describe the TFDM Terminal Publication (TTP) implementation within ATD-2 including data message formats and data schemas.

message format specification↗