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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Generic Ada code in the NASA space station command, control and communications environment

The results of efforts to apply powerful Ada constructs to the formatted message handling process are described. The goal of these efforts was to extend the state-of-technology in message handling while at the same time producing production-quality, reusable code. The first effort was initiated in September, 1984 and delivered in April, 1985. That product, the Generic Message Handling Facility, met initial goals, was reused, and is available in the Ada Repository on ARPANET. However, it became apparent during its development that the initial approach to building a message handler template was not optimal. As a result of this initial effort, several alternate approaches were identified, and research is now on-going to identify an improved product. The ultimate goal is to be able to instantly build a message handling system for any message format given a specification of that message format. The problem lies in how to specify the message format, and one that is done, how to use that information to build the message handler. Message handling systems and message types are described. The initial efforts, its results and its shortcomings are detailed. The approach now being taken to build a system which will be significantly easier to implement, and once implemented, easier to use, is described. Finally, conclusions are offered.

Mcdougall, D. P.↗
NASA NTRS1992

NCC Simulation Model: Simulating the operations of the network control center, phase 2

The simulation of the network control center (NCC) is in the second phase of development. This phase seeks to further develop the work performed in phase one. Phase one concentrated on the computer systems and interconnecting network. The focus of phase two will be the implementation of the network message dialogues and the resources controlled by the NCC. These resources are requested, initiated, monitored and analyzed via network messages. In the NCC network messages are presented in the form of packets that are routed across the network. These packets are generated, encoded, decoded and processed by the network host processors that generate and service the message traffic on the network that connects these hosts. As a result, the message traffic is used to characterize the work done by the NCC and the connected network. Phase one of the model development represented the NCC as a network of bi-directional single server queues and message generating sources. The generators represented the external segment processors. The served based queues represented the host processors. The NCC model consists of the internal and external processors which generate message traffic on the network that links these hosts. To fully realize the objective of phase two it is necessary to identify and model the processes in each internal processor. These processes live in the operating system of the internal host computers and handle tasks such as high speed message exchanging, ISN and NFE interface, event monitoring, network monitoring, and message logging. Inter process communication is achieved through the operating system facilities. The overall performance of the host is determined by its ability to service messages generated by both internal and external processors.

Benjamin, Norman M.↗
NASA NTRS2017

Recent Developments and Future Directions in CCSDS Flight Dynamics Standards

Progress by the Consultative Committee for Space Data Standards (CCSDS) Navigation Working Group in developing international standards for use in space flight dynamics operations has been regularly presented at the ISSFD. Since the last update in 2012, the status of several standards has changed relative to previous reports: the Conjunction Data Message has been published and is widely used, the Pointing Request Message is in final prototyping, the Navigation Hardware Message may be cancelled, the Spacecraft Maneuver Message has been discontinued, a new Re-Entry Data Message standard has been started, the Events Message is about to start, and the "first generation" standards (Orbit Data Messages, Attitude Data Messages, Tracking Data Message, NDM/XML Specification) are being revised. Future directions have primarily arisen in the context of "second generation" standards that supplement first generation standards. The need to duplicate common data structures (e.g., an orbit state) commonly arises. Two important objectives of CCSDS international standards are interoperability and cross-support, which makes consistency essential. Still, maintaining consistency from one standard to another is challenging. The related concepts of duplication and consistency have led to the still evolving notion of a "universal, modular message". Recent discussion suggests this concept may be the way forward.

Berry, David S.↗
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 NTRS1995

ORBCOMM: Initial operations

ORBCOMM, a subsidiary of Orbital Sciences Corporation (OSC), has designed a system to provide low-cost mobile two-way data communications for worldwide commercial markets. The primary application areas are data communications and messaging. The ORBCOMM System has been designed so a user can compose, transmit, and receive messages; control and monitor assets; and collect data on hand-held subscriber communicators (SC's). With a constellation of 36 LEO satellites and terrestrial facilities, users in the temperature climate zones around the world will have a satellite in view over 98% of the time, and will have to wait less than two minutes the rest of the time to directly access a satellite. A message transmitted from a SC and received by the satellite is relayed down to a regional gateway earth station (GES). The GES then transmits the message via fiber land-lines to the network control center (NCC). The NCC then determines the location of the recipient of the message and routes the message accordingly. The NCC can receive and transmit messages from terrestrial networks via X.400 and X.25 gateways. The NCC can translate messages from widely used e-mail systems such as Internet, cc:Mail, and Microsoft Mail into X.400 messages for transmission to and from ORBCOMM SC's.

Schoen, David↗
NASA NTRS2013

Flight Crew Workload, Acceptability, and Performance When Using Data Comm in a High-Density Terminal Area Simulation

This document describes a collaborative FAA/NASA experiment using 22 commercial airline pilots to determine the effect of using Data Comm to issue messages during busy, terminal area operations. Four conditions were defined that span current day to future flight deck equipage: Voice communication only, Data Comm only, Data Comm with Moving Map Display, and Data Comm with Moving Map displaying taxi route. Each condition was used in an arrival and a departure scenario at Boston Logan Airport. Of particular interest was the flight crew response to D-TAXI, the use of Data Comm by Air Traffic Control (ATC) to send taxi instructions. Quantitative data was collected on subject reaction time, flight technical error, operational errors, and eye tracking information. Questionnaires collected subjective feedback on workload, situation awareness, and acceptability to the flight crew for using Data Comm in a busy terminal area. Results showed that 95% of the Data Comm messages were responded to by the flight crew within one minute and 97% of the messages within two minutes. However, post experiment debrief comments revealed almost unanimous consensus that two minutes was a reasonable expectation for crew response. Flight crews reported that Expected D-TAXI messages were useful, and employment of these messages acceptable at all altitude bands evaluated during arrival scenarios. Results also indicate that the use of Data Comm for all evaluated message types in the terminal area was acceptable during surface operations, and during arrivals at any altitude above the Final Approach Fix, in terms of response time, workload, situation awareness, and flight technical performance. The flight crew reported the use of Data Comm as implemented in this experiment as unacceptable in two instances: in clearances to cross an active runway, and D-TAXI messages between the Final Approach Fix and 80 knots during landing roll. Critical cockpit tasks and the urgency of out-the window scan made the additional head down time to respond to Data Comm messages undesirable during these events. However, most crews also stated that Data Comm messages without an accompanying audio chime and no expectation of an immediate response could be acceptable even during these events.

Norman, R. Michael↗
NASA NTRS2018

Design and Development of Responder: a Notification-Acknowledgment Android OS Phone Application

This paper discusses the design and development of the Android phone application Responder and how it assists Flight Operation Team (FOT) members in handling alerts from a Short Message Service (SMS) text message and email based notification system. The FOT needed a simplified and more powerful tool for receiving, storing, and acknowledging notifications sent from the ground systems automated notification software called Attention! (Registered Trademark). The previous system was to rely on a text message application that comes on a phone. This way was slow, inefficient, and did a poor job of keeping FOT members informed on the state of a situation when multiple notifications are being sent out by Attention! (Registered Trademark). Responder is designed to provide easier viewing and acknowledging of multiple messages. It gives the user a quick look at all recently received messages in an organized and clean manner that prevents notifications from being lost during a large burst of messages. It makes it easier to find and review old messages received and Responder was designed to give the user more flexibility in setting up how and what alerts will notify them when they are received by the phone. Since the implementation of Responder the FOT members are more informed and are able to focus more on problem solving the reason a notification was received then trying to keep up with sending cumbersome acknowledgements over text message or email. Responder is only able to receive and send SMS text messages but by using email to text services provided by the cellular carrier it is able to send and receive emails.

notification↗
NASA NTRS2017

Efficient Data Generation and Publication as a Test Tool

A tool to facilitate the generation and publication of test data was created to test the individual components of a command and control system designed to launch spacecraft. Specifically, this tool was built to ensure messages are properly passed between system components. The tool can also be used to test whether the appropriate groups have access (read/write privileges) to the correct messages. The messages passed between system components take the form of unique identifiers with associated values. These identifiers are alphanumeric strings that identify the type of message and the additional parameters that are contained within the message. The values that are passed with the message depend on the identifier. The data generation tool allows for the efficient creation and publication of these messages. A configuration file can be used to set the parameters of the tool and also specify which messages to pass.

command↗
NASA NTRS1989

Fault tolerant hypercube computer system architecture

A fault-tolerant multiprocessor computer system of the hypercube type comprising a hierarchy of computers of like kind which can be functionally substituted for one another as necessary is disclosed. Communication between the working nodes is via one communications network while communications between the working nodes and watch dog nodes and load balancing nodes higher in the structure is via another communications network separate from the first. A typical branch of the hierarchy reporting to a master node or host computer comprises, a plurality of first computing nodes; a first network of message conducting paths for interconnecting the first computing nodes as a hypercube. The first network provides a path for message transfer between the first computing nodes; a first watch dog node; and a second network of message connecting paths for connecting the first computing nodes to the first watch dog node independent from the first network, the second network provides an independent path for test message and reconfiguration affecting transfers between the first computing nodes and the first switch watch dog node. There is additionally, a plurality of second computing nodes; a third network of message conducting paths for interconnecting the second computing nodes as a hypercube. The third network provides a path for message transfer between the second computing nodes; a fourth network of message conducting paths for connecting the second computing nodes to the first watch dog node independent from the third network. The fourth network provides an independent path for test message and reconfiguration affecting transfers between the second computing nodes and the first watch dog node; and a first multiplexer disposed between the first watch dog node and the second and fourth networks for allowing the first watch dog node to selectively communicate with individual ones of the computing nodes through the second and fourth networks; as well as, a second watch dog node operably connected to the first multiplexer whereby the second watch dog node can selectively communicate with individual ones of the computing nodes through the second and fourth networks. The branch is completed by a first load balancing node; and a second multiplexer connected between the first load balancing node and the first and second watch dog nodes, allowing the first load balancing node to selectively communicate with the first and second watch dog nodes.

Madan, Herb S.↗
NASA NTRS1997

Cooperative Data Sharing: Simple Support for Clusters of SMP Nodes

Libraries like PVM and MPI send typed messages to allow for heterogeneous cluster computing. Lower-level libraries, such as GAM, provide more efficient access to communication by removing the need to copy messages between the interface and user space in some cases. still lower-level interfaces, such as UNET, get right down to the hardware level to provide maximum performance. However, these are all still interfaces for passing messages from one process to another, and have limited utility in a shared-memory environment, due primarily to the fact that message passing is just another term for copying. This drawback is made more pertinent by today's hybrid architectures (e.g. clusters of SMPs), where it is difficult to know beforehand whether two communicating processes will share memory. As a result, even portable language tools (like HPF compilers) must either map all interprocess communication, into message passing with the accompanying performance degradation in shared memory environments, or they must check each communication at run-time and implement the shared-memory case separately for efficiency. Cooperative Data Sharing (CDS) is a single user-level API which abstracts all communication between processes into the sharing and access coordination of memory regions, in a model which might be described as "distributed shared messages" or "large-grain distributed shared memory". As a result, the user programs to a simple latency-tolerant abstract communication specification which can be mapped efficiently to either a shared-memory or message-passing based run-time system, depending upon the available architecture. Unlike some distributed shared memory interfaces, the user still has complete control over the assignment of data to processors, the forwarding of data to its next likely destination, and the queuing of data until it is needed, so even the relatively high latency present in clusters can be accomodated. CDS does not require special use of an MMU, which can add overhead to some DSM systems, and does not require an SPMD programming model. unlike some message-passing interfaces, CDS allows the user to implement efficient demand-driven applications where processes must "fight" over data, and does not perform copying if processes share memory and do not attempt concurrent writes. CDS also supports heterogeneous computing, dynamic process creation, handlers, and a very simple thread-arbitration mechanism. Additional support for array subsections is currently being considered. The CDS1 API, which forms the kernel of CDS, is built primarily upon only 2 communication primitives, one process initiation primitive, and some data translation (and marshalling) routines, memory allocation routines, and priority control routines. The entire current collection of 28 routines provides enough functionality to implement most (or all) of MPI 1 and 2, which has a much larger interface consisting of hundreds of routines. still, the API is small enough to consider integrating into standard os interfaces for handling inter-process communication in a network-independent way. This approach would also help to solve many of the problems plaguing other higher-level standards such as MPI and PVM which must, in some cases, "play OS" to adequately address progress and process control issues. The CDS2 API, a higher level of interface roughly equivalent in functionality to MPI and to be built entirely upon CDS1, is still being designed. It is intended to add support for the equivalent of communicators, reduction and other collective operations, process topologies, additional support for process creation, and some automatic memory management. CDS2 will not exactly match MPI, because the copy-free semantics of communication from CDS1 will be supported. CDS2 application programs will be free to carefully also use CDS1. CDS1 has been implemented on networks of workstations running unmodified Unix-based operating systems, using UDP/IP and vendor-supplied high- performance locks. Although its inter-node performance is currently unimpressive due to rudimentary implementation technique, it even now outperforms highly-optimized MPI implementation on intra-node communication due to its support for non-copy communication. The similarity of the CDS1 architecture to that of other projects such as UNET and TRAP suggests that the inter-node performance can be increased significantly to surpass MPI or PVM, and it may be possible to migrate some of its functionality to communication controllers.

DiNucci, David C.↗
NASA NTRS2001

Re-Examination of Mixed Media Communication: The Impact of Voice, Data Link, and Mixed Air Traffic Control Environments on the Flight Deck

A simulation in the B747-400 was conducted at NASA Ames Research Center that compared how crews handled voice and data link air traffic control (ATC) messages in a single medium versus a mixed voice and data link ATC environment The interval between ATC messages was also varied to examine the influence of time pressure in voice, data link, and mixed ATC environments. For messages sent via voice, transaction times were lengthened in the mixed media environment for closely spaced messages. The type of environment did not affect data link times. However, messages times were lengthened in both single and mixed-modality environments under time pressure. Closely spaced messages also increased the number of requests for clarification for voice messages in the mixed environment and review menu use for data link messages. Results indicated that when time pressure is introduced, the mix of voice and data link does not necessarily capitalize on the advantages of both media. These findings emphasize the need to develop procedures for managing communication in mixed voice and data link environments.

Dunbar, Melisa↗
NASA NTRSDate not supplied

Lunar Search & Rescue Applications of Lunar GNSS

Accurate lunar navigation and timing knowledge provides for the development of safety-critical services in the cislunar and lunar surface domain. Currently under development, the Goddard Space Flight Center’s (GSFC) Search and Rescue Mission Office is investigating and integrating search and rescue (SAR) capability into planned and future lunar communication and navigation interfaces. Lunar Search and Rescue (LunaSAR) development has a stated end-goal for assured, reliable, and timely indication of distress events for a wide variety of lunar surface users, including government-sponsored, commercial, and international users. LunaSAR performance requirements are modelled after the current terrestrial Cospas-Sarsat distress notification system, leveraging an internationally robust global navigation satellite system (GNSS) ecosystem as a core element of survivor locating capability. This presentation will discuss NASA’s work to develop user-focused distress messaging capabilities including infusion of example sensor data for triggering of automated distress alerts coupled with location-tagging. Additionally, the presentation will examine overall message structures, rotating fields for use in bi-directional distress messaging, and specific use cases based on NASA’s lunar exploration and lunar communication relay architectures. Modelling and simulation of LunaSAR use by individual lunar explorers will be discussed, based on notional industry and government design reference missions and mission considerations. Results from GSFC-funded Internal Research and Development (IRAD) efforts will be detailed, including successful distress message formulation simulating the ingestion of example legacy space suit telemetry fields. Hardware-in-the-loop testing using high-reliability software defined radio (SDR) modules serve as an example of IRAD successes and the framework for technical requirements. Architectural development and technical evolution from 2020 to 2021 included alignment of LunaSAR distress waveforms with ongoing NASA LunaNet interoperability development, as well as engagement with NASA Lunar Spectrum authorities for allocation of UHF-band distress frequencies on the lunar surface. S-Band and UHF-band transmission characteristics will be detailed, along with band-specific applications of each emission type. Additionally, examples of ingestion and formatting of GNSS signals (using historical terrestrial National Marine Electronics Association-formatted GNSS data) will be detailed, underscoring lunar user needs for a common lunar GNSS receiver output message framework. Maturity and ability to support evolving lunar exploration goals has been demonstrated and will be detailed, with maturity gaps such as position, navigation, and timing (PNT) and lunar reference frames identified within the context of distress message generation. Provision of LunaSAR services for lunar surface users represents a new era of ensured safety for lunar explorers and builds off of forty years of the Cospas-Sarsat program, underscoring the importance of lunar GNSS for safety-critical applications and growing interest in safe, reliable lunar surface operations. Enabled by new GNSS systems being developed by government and industry partners, NASA will continue to evolve and integrate lunar GNSS types into distress message generation, with a focus on compact and efficient message transmission over various lunar communication links. When fielded, LunaSAR will be the first dedicated search and rescue notification system employed on another celestial body. Robust lunar navigation and timing services form the core of LunaSAR capabilities, allowing for system syncing with time-dominant sensors, and high-accuracy location of those in distress while engaged in lunar surface activities.

Search and Rescue↗
NASA NTRS1976

Basic limits on protocol information in data communications networks

The paper considers basic limitations on the amount of protocol information that must be transmitted in a data communication network to keep track of source and receiver addresses and of the starting and stopping of messages. Assuming Poisson message arrivals between each communicating source-receiver pair, a lower bound is found on the required protocol information for message. This lower bound is the sum of two terms, one for the message-length information, which depends only on the distribution of message lengths, and the other for the message-start information, which depends only on the product of the source-receiver pair arrival rate and the expected delay for transmitting the message. Two strategies are developed which, in the limit of large numbers of sources and receivers, almost meet the lower bound on protocol information.

Gallager, R. G.↗
NASA NTRS1992

High performance interconnection between high data rate networks

The bridge/gateway system needed to interconnect a wide range of computer networks to support a wide range of user quality-of-service requirements is discussed. The bridge/gateway must handle a wide range of message types including synchronous and asynchronous traffic, large, bursty messages, short, self-contained messages, time critical messages, etc. It is shown that messages can be classified into three basic classes, synchronous and large and small asynchronous messages. The first two require call setup so that packet identification, buffer handling, etc. can be supported in the bridge/gateway. Identification enables resequences in packet size. The third class is for messages which do not require call setup. Resequencing hardware based to handle two types of resequencing problems is presented. The first is for a virtual parallel circuit which can scramble channel bytes. The second system is effective in handling both synchronous and asynchronous traffic between networks with highly differing packet sizes and data rates. The two other major needs for the bridge/gateway are congestion and error control. A dynamic, lossless congestion control scheme which can easily support effective error correction is presented. Results indicate that the congestion control scheme provides close to optimal capacity under congested conditions. Under conditions where error may develop due to intervening networks which are not lossless, intermediate error recovery and correction takes 1/3 less time than equivalent end-to-end error correction under similar conditions.

Foudriat, E. C.↗
NASA NTRS1998

Defining the ATC Controller Interface for Data Link Clearances

The Controller Interface (CI) is the primary method for Air Traffic Controllers to communicate with aircraft via Controller-Pilot Data Link Communications (CPDLC). The controller, wearing a microphone/headset, aurally gives instructions to aircraft as he/she would with today's voice radio systems. The CI's voice recognition system converts the instructions to digitized messages that are formatted according to the RTCA DO-219 Operational Performance Standards for ATC Two-Way Data Link Communications. The DO-219 messages are transferred via RS-232 to the ATIDS system for uplink using a Mode-S datalink. Pilot acknowledgments of controller messages are downlinked to the ATIDS system and transferred to the Cl. A computer monitor is used to convey information to the controller. Aircraft data from the ARTS database are displayed on flight strips. The flight strips are electronic versions of the strips currently used in the ATC system. Outgoing controller messages cause the respective strip to change color to indicate an unacknowledged transmission. The message text is shown on the flight strips for reference. When the pilot acknowledges the message, the strip returns to its normal color. A map of the airport can also be displayed on the monitor. In addition to voice recognition, the controller can enter messages using the monitor's touch screen or by mouse/keyboard.

Rankin, James↗
NASA NTRS1994

An Experimental Evaluation of Data Link Textual Formats

Problems resulting from the use of verbal communications in the National Airspace System have lead to an increasing necessity for digitized air-ground communications or data link. This report describes an investigation of digitized communications through the evaluation of message length and different textual formats of clearance data. Current line pilots flew in a part-task simulation where the message length (one message with four commands vs. two messages with two commands each) and the textual format of ATC clearances were varied. Pilots also monitored a secondary task while flying. Secondary task measures and data link response times revealed no significant differences between the two formats under investigation. Message length did impact communication timing with only the first of a pair of two short messages resulting in significantly faster response times than either the second short or long message types.

McGann, Alison↗
NASA NTRS2004

Simulation of Controller Pilot Data Link Communications over VHF Digital Link Mode 3

The Federal Aviation Administration (FAA) has established an operational plan for the future Air Traffic Management (ATM) system, in which the Controller Pilot Data Link Communications (CPDLC) is envisioned to evolve into digital messaging that will take on an ever increasing role in controller to pilot communications, significantly changing the way the National Airspace System (NAS) is operating. According to FAA, CPDLC represents the first phase of the transition from the current analog voice system to an International Civil Aviation Organization (ICAO) compliant system in which digital communication becomes the alternate and perhaps primary method of routine communication. The CPDLC application is an Air Traffic Service (ATS) application in which pilots and controllers exchange messages via an addressed data link. CPDLC includes a set of clearance, information, and request message elements that correspond to existing phraseology employed by current Air Traffic Control (ATC) procedures. These message elements encompass altitude assignments, crossing constraints, lateral deviations, route changes and clearances, speed assignments, radio frequency assignments, and various requests for information. The pilot is provided with the capability to respond to messages, to request clearances and information, to report information, and to declare/rescind an emergency. A 'free text' capability is also provided to exchange information not conforming to defined formats. This paper presents simulated results of the aeronautical telecommunication application Controller Pilot Data Link Communications over VHF Digital Link Mode 3 (VDL Mode 3). The objective of this simulation study was to determine the impact of CPDLC traffic loads, in terms of timely message delivery and capacity of the VDL Mode 3 subnetwork. The traffic model is based on and is used for generating air/ground messages with different priorities. Communication is modeled for the en route domain of the Cleveland Center air traffic (ZOB ARTCC).

Bretmersky, Steven C.↗
NASA NTRS2005

Increasing the Automation and Autonomy for Spacecraft Operations with Criteria Action Table

The Criteria Action Table (CAT) is an automation tool developed for monitoring real time system messages for specific events and processes in order to take user defined actions based on a set of user-defined rules. CAT was developed by Lockheed Martin Space Operations as a part of a larger NASA effort at the Goddard Space Flight Center (GSFC) to create a component-based, middleware-based, and standard-based general purpose ground system architecture referred as GMSEC - the GSFC Mission Services Evolution Center. CAT has been integrated into the upgraded ground systems for Tropical Rainfall Measuring Mission (TRMM) and Small Explorer (SMEX) satellites and it plays the central role in their automation effort to reduce the cost and increase the reliability for spacecraft operations. The GMSEC architecture provides a standard communication interface and protocol for components to publish/describe messages to an information bus. It also provides a standard message definition so components can send and receive messages to the bus interface rather than each other, thus reducing the component-to-component coupling, interface, protocols, and link (socket) management. With the GMSEC architecture, components can publish standard event messages to the bus for all nominal, significant, and surprising events in regard to satellite, celestial, ground system, or any other activity. In addition to sending standard event messages, each GMSEC compliant component is required to accept and process GMSEC directive request messages.

Li, Zhen-Ping↗