Search NASA⌕ Search

SEARCH · Search NASA

Results for “message systems”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Launch Control System Message Reduction

System Monitoring and Control (SMC) message browsers receive many messages daily that operators do not need to see. My job is to reduce the number of messages so that warning and emergency messages can be seen easily and therefore, responded to promptly. There are two methods to reduce messages: duplicate and state-based message correlations. With duplicate message correlation, SMC display the message the first time it shows up. The next times it occurs, a duplicate number will count the number of times the message appears. State-based message correlation is a process in which more informative messages acknowledge less useful ones and send them to history. I also work on correcting the severity level and text formats of messages. I follow two SMC message filtering tenets as I'm working on this project. Firstly, before filtering an offending message, a non-conformance (NC) must be created in order to attempt fixing that message through hardware or software. Only after the NC assessment states that it cannot fix an offending message, it can be filtered by SMC. Secondly, per Launch Control System (LCS) Coding Standards, SMC does not send information messages to the active message browser unless it's a response to an operator action.

correlation↗
NASA NTRS1997

Increased User Satisfaction Through an Improved Message System

With all of the enhancements in software methodology and testing, there is no guarantee that software can be delivered such that no user errors occur, How to handle these errors when they occur has become a major research topic within human-computer interaction (HCI). Users of the Multimission Spacecraft Analysis Subsystem(MSAS) at the Jet Propulsion Laboratory (JPL), a system of X and motif graphical user interfaces for analyzing spacecraft data, complained about the lack of information about the error cause and have suggested that recovery actions be included in the system error messages...The system was evaluated through usability surveys and was shown to be successful.

Human-computer interaction error handling direct m↗
NASA NTRS2002

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↗
NASA NTRS2017

MESA: Message-Based System Analysis Using Runtime Verification

In this paper, we present a novel approach and framework for run-time verication of large, safety critical messaging systems. This work was motivated by verifying the System Wide Information Management (SWIM) project of the Federal Aviation Administration (FAA). SWIM provides live air traffic, site and weather data streams for the whole National Airspace System (NAS), which can easily amount to several hundred messages per second. Such safety critical systems cannot be instrumented, therefore, verification and monitoring has to happen using a nonintrusive approach, by connecting to a variety of network interfaces. Due to a large number of potential properties to check, the verification framework needs to support efficient formulation of properties with a suitable Domain Specific Language (DSL). Our approach is to utilize a distributed system that is geared towards connectivity and scalability and interface it at the message queue level to a powerful verification engine. We implemented our approach in the tool called MESA: Message-Based System Analysis, which leverages the open source projects RACE (Runtime for Airspace Concept Evaluation) and TraceContract. RACE is a platform for instantiating and running highly concurrent and distributed systems and enables connectivity to SWIM and scalability. TraceContract is a runtime verication tool that allows for checking traces against properties specified in a powerful DSL. We applied our approach to verify a SWIM service against several requirements.We found errors such as duplicate and out-of-order messages.

Message-based System↗
NASA NTRS2006

Collaborative Scheduling Using JMS in a Mixed Java and .NET Environment

A collaborative framework/environment was proto-typed to prove the feasibility of scheduling space flight missions on NASA's Deep Space Network (DSN) in a distributed fashion. In this environment, effective collaboration relies on efficient communications among all flight mission and DSN scheduling users. There-fore, messaging becomes critical to timely event notification and data synchronization. In the prototype, a rapid messaging system using Java Message Service (JMS) in a mixed Java and .NET environment is established. This scheme allows both Java and .NET applications to communicate with each other for data synchronization and schedule negotiation. The JMS approach we used is based on a centralized messaging scheme. With proper use of a high speed messaging system, all users in this collaborative framework can communicate with each other to generate a schedule collaboratively to meet DSN and projects tracking needs.

scheduling↗
NASA NTRS2015

Using Publish-Subscribe Messaging for System Status and Automation

The NASA Goddard Mission Services Evolution Center (GMSEC) system is a message-based plug-and-play open system architecture used in many of NASA mission operations centers. This presentation will focus on the use of GMSEC standard messages to report and analyze the status of a system and enable the automation of the system's components. In GMSEC systems, each component reports its status using a keep-alive message and also publishes status and activities as log messages. In addition, the components can accept functional directive messages from the GMSEC message bus. Over the past several years, development teams have found ways to utilize these messages to create innovative display pages and increasingly sophisticated approaches to automation. This presentation will show the flexibility and value of the message-based approach to system awareness and automation.

Enterprise↗
NASA NTRS1993

Space Reclamation for Uncoordinated Checkpointing in Message-Passing Systems

Checkpointing and rollback recovery are techniques that can provide efficient recovery from transient process failures. In a message-passing system, the rollback of a message sender may cause the rollback of the corresponding receiver, and the system needs to roll back to a consistent set of checkpoints called recovery line. If the processes are allowed to take uncoordinated checkpoints, the above rollback propagation may result in the domino effect which prevents recovery line progression. Traditionally, only obsolete checkpoints before the global recovery line can be discarded, and the necessary and sufficient condition for identifying all garbage checkpoints has remained an open problem. A necessary and sufficient condition for achieving optimal garbage collection is derived and it is proved that the number of useful checkpoints is bounded by N(N+1)/2, where N is the number of processes. The approach is based on the maximum-sized antichain model of consistent global checkpoints and the technique of recovery line transformation and decomposition. It is also shown that, for systems requiring message logging to record in-transit messages, the same approach can be used to achieve optimal message log reclamation. As a final topic, a unifying framework is described by considering checkpoint coordination and exploiting piecewise determinism as mechanisms for bounding rollback propagation, and the applicability of the optimal garbage collection algorithm to domino-free recovery protocols is demonstrated.

Wang, Yi-Min↗
NASA NTRS1990

Message handling system concepts and services in a land mobile satellite system

A network architecture containing the capabilities offered by the Message Handling System (MHS) to the PRODAT Land Mobile Satellite System (LMSS) is described taking into account the constraints of a preexisting satellite system which is going to become operational. The mapping between MHS services and PRODAT requirements is also reported and shows that the supplied performance can be significantly enhanced to both fixed and mobile users. The impact of the insertion of additional features on the system structure, especially on the centralized control unit, are also addressed.

Barberis, S.↗
NASA NTRS1989

The structure of the clouds distributed operating system

A novel system architecture, based on the object model, is the central structuring concept used in the Clouds distributed operating system. This architecture makes Clouds attractive over a wide class of machines and environments. Clouds is a native operating system, designed and implemented at Georgia Tech. and runs on a set of generated purpose computers connected via a local area network. The system architecture of Clouds is composed of a system-wide global set of persistent (long-lived) virtual address spaces, called objects that contain persistent data and code. The object concept is implemented at the operating system level, thus presenting a single level storage view to the user. Lightweight treads carry computational activity through the code stored in the objects. The persistent objects and threads gives rise to a programming environment composed of shared permanent memory, dispensing with the need for hardware-derived concepts such as the file systems and message systems. Though the hardware may be distributed and may have disks and networks, the Clouds provides the applications with a logically centralized system, based on a shared, structured, single level store. The current design of Clouds uses a minimalist philosophy with respect to both the kernel and the operating system. That is, the kernel and the operating system support a bare minimum of functionality. Clouds also adheres to the concept of separation of policy and mechanism. Most low-level operating system services are implemented above the kernel and most high level services are implemented at the user level. From the measured performance of using the kernel mechanisms, we are able to demonstrate that efficient implementations are feasible for the object model on commercially available hardware. Clouds provides a rich environment for conducting research in distributed systems. Some of the topics addressed in this paper include distributed programming environments, consistency of persistent data and fault-tolerance.

Dasgupta, Partha↗
NASA NTRS2020

What Can We Learn from One Billion Ground System Log Messages?

Shortage of log-based data in a ground system they have traditionally been the under achievers in a satellite ground system. This is due to several factors: Once log messages scroll out of view on the TTC event console window they are soon forgotten. Application and system log files are scattered across directories within a system, across a multitude of servers, and across one or more databases making access cumbersome. Typical tools to perform log file content searching are generally crude and typically only employed as part of trouble-shooting exercises.As we move towards satellite constellations and fleets and add even more status information, the number of messages keeps growing. One mission now estimates that they could generate 3,000,000 messages per day 1 billion per year - for the life of their mission. What to do with those 1 billion messages? That is the challenge. With the recent technological advances in the management of large data sets, text-based processing, and data analytics, there are now capabilities that we can provide to the ground system engineers and satellite operators to address what we postulate are missed opportunities. Advanced real-time log analysis can allow us to be less reactionary in favor of being more proactive. Analytics goals include the ability to: Identify root cause of unexpected events, failures or error conditions enabled by correlating disparate data. Detect security breaches attempts before they are successful. Help admins ensure IT resources continue running optimally. Identify trends and patterns that may indicate impending failures or error conditions for valuable assets before they happen. Compare satellites in a fleet or constellation in terms of number of alarms, number of command sent to them, etc.. Answer questions like "Are the operations support needs increasing over the past year?" or "Have we seen this combination of alarm conditions before?" But really, once the tools are readily available the users will start realizing what can be done with their new powers. In this presentation we will show the results of analyzing millions of actual mission operations log messages, how the results can be displayed to the user, and how new products now available as open source can be applied to the challenges of large scale time-tagged text-based mission operations messages. Flight operations team members believe that this is a powerful new option for how they assess overall system and space asset health. Technical descriptions of the design, tools, and storage will be provided. One billion messages? Bring'em on!

Orsborne, Sharon↗
NASA NTRS2010

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↗
NASA NTRS1993

A distributed Clips implementation: dClips

A distributed version of the Clips language, dClips, was implemented on top of two existing generic distributed messaging systems to show that: (1) it is easy to create a coarse-grained parallel programming environment out of an existing language if a high level messaging system is used; and (2) the computing model of a parallel programming environment can be changed easily if we change the underlying messaging system. dClips processes were first connected with a simple master-slave model. A client-server model with intercommunicating agents was later implemented. The concept of service broker is being investigated.

Li, Y. Philip↗
NASA NTRS2014

Launch Control System Master Console Event Message Reduction

System monitoring and control (SMC) message browsers receive so many messages daily that operators do not need to see. Important messages are often mixed up among the less important ones. My job is to reduce the messages displayed in the message browser so that warning and emergency messages can be seen easily and therefore, responded promptly. There are multiple methods to achieve this. Firstly, duplicate messages should not appear many times in the message browser. Instead, the message should appear only once but with a number that counts the times that it appears. This method is called duplicate message suppression. Secondly, messages that update the most recent state (e.g. up/down) of a component should replace the old-state messages. This method is called state based message correlation. Thirdly, messages that display "normal" alarm level should be suppressed unless it's a response to an operator action. In addition to message reduction, I also work on correcting the severity level and text formats on messages.

messages↗
NASA NTRS1992

The data acquisition system for the Anglo-Australian Observatory 2-degree field project

The Anglo-Australian Observatory (AAO) is building a system that will provide a two-degree field of view at prime focus. A robot positioner will be used to locate up to 400 optical fibers at pre-determined positions in this field. While observations are being made using one set of 400 fibers, the robot will be positioning a second set of fibers in a background field that can be moved in to replace the first when the telescope is moved to a new position. The fibers feed two spectrographs each with a 1024 square CCD detector. The software system being produced to control this involves Vaxes for overall control and data recording, UNIX workstations for fiber configuration calculations and on-line data reduction, and VME systems running VxWorks for real-time control of critical parts such as the positioner robot. The system has to be able to interact with the observatory's present data acquisition systems, which use the ADAM system. As yet, the real-time parts of ADAM have not been ported to Unix, and so we are having to produce a smaller-scale system that is similar but inherently distributed (which ADAM is not). We are using this system as a testbed for ideas that we hope may eventually influence an ADAM II system. The system we are producing is based on a message system that is designed to be able to handle inter-process and inter-processor messages of any length, efficiently, and without ever requiring a task to block (i.e., be unresponsive to 'cancel' messages, enquiry messages), other than when deliberately waiting for external input - all of which will be through such messages. The essential requirement is that a message 'send' operation should never be able to block. The messages will be hierarchical, self-defining, machine-independent data structures. This allows us to provide very simple monitoring of messages for diagnostic purposes, and allows general purpose interface programs to be written without needing to share precise byte by byte message format definitions. Programs in this system have interfaces defined simply in terms of named actions and their parameters. Real-time control programs are required to be able to handle a number of such actions concurrently; data reduction programs will normally only need to handle one action at a time ('process an image', 'display a spectrum', etc).

Shortridge, K.↗
NASA NTRS2008

Re-Engineering the Tropical Rainfall Measuring Mission (TRMM) Satellite Utilizing Goddard Space Flight Center (GSFC) Mission Services Center (GMSEC) Middleware Based Technology to Enable Lights Out Operations and Autonomous Re-Dump of Lost Telemetry Data

The Tropical Rainfall Measuring Mission (TRMM) spacecraft was launched in November of 1996 in order to obtain unique three dimensional radar cross sectional observations of cloud structures with particular interest in hurricanes. The TRMM mission life was recently extended with current estimates that operations will continue through the 2012-2013 timeframe. Faced with this extended mission profile, the project has embarked on a technology refresh and re-engineering effort. TRMM has recently implemented a re-engineering effort to expand a middleware based messaging architecture to enable fully redundant lights-out of flight operations activities. The middleware approach is based on the Goddard Mission Services Evolution Center (GMSEC) architecture, tools and associated open-source Applications Programming Interface (API). Middleware based messaging systems are useful in spacecraft operations and automation systems because private node based knowledge (such as that within a telemetry and command system) can be broadcast on the middleware messaging bus and hence enable collaborative decisions to be made by multiple subsystems. In this fashion, private data is made public and distributed within the local area network and multiple nodes can remain synchronized with other nodes. This concept is useful in a fully redundant architecture whereby one node is monitoring the processing of the 'prime' node so that in the event of a failure the backup node can assume operations of the prime, without loss of state knowledge. This paper will review and present the experiences, architecture, approach and lessons learned of the TRMM re-engineering effort centered on the GMSEC middleware architecture and tool suite. Relevant information will be presented that relates to the dual redundant parallel nature of the Telemetry and Command (T and C) and Front-End systems and how these systems can interact over a middleware bus to achieve autonomous operations including autonomous commanding to recover missing science data during the same spacecraft contact.

Marius, Julio L.↗
NASA NTRS1988

Hardware realization of a baseband processor for a SS-FDMA/TDMA/DAMA system

Hardware implementation of the NASA ACTS baseband processor is described which achieves the system message data handling performance required to perform satellite switching of high-rate baseband data. The hardware meets payload specifications for size, weight, and power. Hardware redundancy applied to critical paths in several functional areas insures that the reliability and life expectancy requirements are fulfilled. The remote reprogrammability of the processor message data handling and routing functions provides system flexibility for dynamic reconfiguration during rapidly changing traffic loads.

Moat, Richard L.↗