Search NASA⌕ Search

SEARCH · Search NASA

Results for “support uplink support”

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 37 records · Page 2

Orion Optical Navigation for Loss of Communication Lunar Return Contingencies

The Orion Crew Exploration Vehicle (CEV) will replace the Space Shuttle and serve as the next-generation spaceship to carry humans back to the Moon for the first time since the Apollo program. For nominal lunar mission operations, the Mission Control Navigation team will utilize radiometric measurements to determine the position and velocity of Orion and uplink state information to support Lunar return. However, in the loss of communications contingency return scenario, Orion must safely return the crew to the Earth's surface. The navigation design solution for this loss of communications scenario is optical navigation consisting of lunar landmark tracking in low lunar orbit and star- horizon angular measurements coupled with apparent planetary diameter for Earth return trajectories. This paper describes the optical measurement errors and the navigation filter that will process those measurements to support navigation for safe crew return.

Getchius, Joel↗

Deep Space C3 : high power uplinks

The uplink transmitters of the Deep Space Network (DSN) perform three key functions in support of space missions: navigation, command uplink, and emergency recovery. The transmitters range in frequency from S-band to Ka-band, and range in RF transmit power from 200W to 400kW. Future improvements to the uplink transmitters will focus on higher frequency transmitters for high data rate communications, high power X-band uplinks for emergency recovery, and /or in-phase uplink arraying for either application

Morabito, David D.↗

Linear Covariance Techniques to Analyze a Multi-Vehicle, Multi-GN&C System with Applications to Rendezvous in a Near Rectilinear Halo Orbit

Typically for a rendezvous and docking scenario, only a single vehicle is considered the active vehicle. As a result, the target vehicle’s GN&C system is typically not a factor in the integrated performance analysis as it assumes a passive role. However, for upcoming NASA Artemis missions the active vehicle is both the chaser and target spacecraft. In addition, both vehicles are cooperating with one another, sharing telemetry data, and relying on data extracted from the GN&C system of the other. The process also includes a team of ground support personnel in mission control are tracking and monitoring each spacecraft uplinking state estimates and targeting solutions to support mission operations and enhance the onboard flight system performance. Being able to quickly analyze the impact of both vehicles with two different GN&C systems that also interact with the ground that does its own navigation and targeting uploads is critical. This paper outlines how to perform this rapid analysis using linear covariance techniques and applies them to a rendezvous scenario initiated in low lunar orbit and completed in a Near Rectilinear Halo Orbit (NRHO) representative of the NASA Artemis III mission.

Linear Covariance Analysis↗

Plant Habitat Telemetry / Command Interface and E-MIST

Plant Habitat (PH) is an experiment to be taken to the International Space Station (ISS) in 2016. It is critical that ground support computers have the ability to uplink commands to control PH, and that ISS computers have the ability to downlink PH telemetry data to ground support. This necessitates communication software that can send, receive, and process, PH specific commands and telemetry. The objective of the Plant Habitat Telemetry/ Command Interface is to provide this communication software, and to couple it with an intuitive Graphical User Interface (GUI). Initial investigation of the project objective led to the decision that code be written in C++ because of its compatibility with existing source code infrastructures and robustness. Further investigation led to a determination that multiple Ethernet packet structures would need to be created to effectively transmit data. Setting a standard for packet structures would allow us to distinguish these packets that would range from command type packets to sub categories of telemetry packets. In order to handle this range of packet types, the conclusion was made to take an object-oriented programming approach which complemented our decision to use the C++ programming language. In addition, extensive utilization of port programming concepts was required to implement the core functionality of the communication software. Also, a concrete understanding of a packet processing software was required in order to put aU the components of ISS-to-Ground Support Equipment (GSE) communication together and complete the objective. A second project discussed in this paper is Exposing Microbes to the Stratosphere (EMIST). This project exposes microbes into the stratosphere to observe how they are impacted by atmospheric effects. This paper focuses on the electrical and software expectations of the project, specifically drafting the printed circuit board, and programming the on-board sensors. The Eagle Computer-Aided Drafting (CAD) software was used to draft the E-MIST circuit. This required several component libraries to be created. Coding the sensors and obtaining sensor data involved using the Arduino Uno developmental board and coding language, and properly wiring peripheral sensors to the microcontroller (the central control unit of the experiment).

Walker, Uriae M.↗

Use of Semi-Autonomous Tools for ISS Commanding and Monitoring

As the International Space Station (ISS) has moved into a utilization phase, operations have shifted to become more ground-based with fewer mission control personnel monitoring and commanding multiple ISS systems. This shift to fewer people monitoring more systems has prompted use of semi-autonomous console tools in the ISS Mission Control Center (MCC) to help flight controllers command and monitor the ISS. These console tools perform routine operational procedures while keeping the human operator "in the loop" to monitor and intervene when off-nominal events arise. Two such tools, the Pre-positioned Load (PPL) Loader and Automatic Operators Recorder Manager (AutoORM), are used by the ISS Communications RF Onboard Networks Utilization Specialist (CRONUS) flight control position. CRONUS is responsible for simultaneously commanding and monitoring the ISS Command & Data Handling (C&DH) and Communications and Tracking (C&T) systems. PPL Loader is used to uplink small pieces of frequently changed software data tables, called PPLs, to ISS computers to support different ISS operations. In order to uplink a PPL, a data load command must be built that contains multiple user-input fields. Next, a multiple step commanding and verification procedure must be performed to enable an onboard computer for software uplink, uplink the PPL, verify the PPL has incorporated correctly, and disable the computer for software uplink. PPL Loader provides different levels of automation in both building and uplinking these commands. In its manual mode, PPL Loader automatically builds the PPL data load commands but allows the flight controller to verify and save the commands for future uplink. In its auto mode, PPL Loader automatically builds the PPL data load commands for flight controller verification, but automatically performs the PPL uplink procedure by sending commands and performing verification checks while notifying CRONUS of procedure step completion. If an off-nominal condition occurs during procedure execution, PPL Loader notifies CRONUS through popup messages, allowing CRONUS to examine the situation and choose an option of how PPL loader should proceed with the procedure. The use of PPL Loader to perform frequent, routine PPL uplinks offloads CRONUS to better monitor two ISS systems. It also reduces procedure performance time and decreases risk of command errors. AutoORM identifies ISS communication outage periods and builds commands to lock, playback, and unlock ISS Operations Recorder files. Operation Recorder files are circular buffer files of continually recorded ISS telemetry data. Sections of these files can be locked from further writing, be played back to capture telemetry data that occurred during an ISS loss of signal (LOS) period, and then be unlocked for future recording use. Downlinked Operation Recorder files are used by mission support teams for data analysis, especially if failures occur during LOS. The commands to lock, playback, and unlock Operations Recorder files are encompassed in three different operational procedures and contain multiple user-input fields. AutoORM provides different levels of automation for building and uplinking the commands to lock, playback, and unlock Operations Recorder files. In its automatic mode, AutoORM automatically detects ISS LOS periods, then generates and uplinks the commands to lock, playback, and unlock Operations Recorder files when MCC regains signal with ISS. AutoORM also features semi-autonomous and manual modes which integrate CRONUS more into the command verification and uplink process. AutoORMs ability to automatically detect ISS LOS periods and build the necessary commands to preserve, playback, and release recorded telemetry data greatly offloads CRONUS to perform more high-level cognitive tasks, such as mission planning and anomaly troubleshooting. Additionally, since Operations Recorder commands contain numerical time input fields which are tedious for a human to manually build, AutoORM's ability to automatically build commands reduces operational command errors. PPL Loader and AutoORM demonstrate principles of semi-autonomous operational tools that will benefit future space mission operations. Both tools employ different levels of automation to perform simple and routine procedures, thereby offloading human operators to perform higher-level cognitive tasks. Because both tools provide procedure execution status and highlight off-nominal indications, the flight controller is able to intervene during procedure execution if needed. Semi-autonomous tools and systems that can perform routine procedures, yet keep human operators informed of execution, will be essential in future long-duration missions where the onboard crew will be solely responsible for spacecraft monitoring and control.

Brzezinski, Amy S.↗

The Transition from Spacecraft Development Ot Flight Operation: Human Factor Considerations

In the field of aeronautics and astronautics, a paradigm shift has been witnessed by those in academia, research and development, and private industry. Long development life cycles and the budgets to support such programs and projects has given way to aggressive task schedules and leaner resources to draw from all the while challenging assigned individuals to create and produce improved products of processes. however, this "faster, better, cheaper" concept cannot merely be applied to the design, development, and test of complex systems such as earth-orbiting of interplanetary robotic spacecraft. Full advantage is not possible without due consideration and application to mission operations planning and flight operations, Equally as important as the flight system, the mission operations system consisting of qualified personnel, ground hardware and software tools, and verified and validated operational processes, should also be regarded as a complex system requiring personnel to draw upon formal education, training, related experiences, and heuristic reasoning in engineering an effective and efficient system. Unquestionably, qualified personnel are the most important elements of a mission operations system. This paper examines the experiences of the Deep Space I Project, the first in a series of new technology in-flight validation missions sponsored by the United States National Aeronautics and Space Administration (NASA), specifically, in developing a subsystems analysis and technology validation team comprised of former spacecraft development personnel. Human factor considerations are investigated from initial concept/vision formulation; through operational process development; personnel test and training; to initial uplink product development and test support. Emphasis has been placed on challenges and applied or recommended solutions, so as to provide opportunities for future programs and projects to address and disposition potential issues and concerns as early as possible to reap the benefits associated with learning from other's past experiences.

Basilio, Ralph R.↗

A new multi-mission data system for space flight support through the 1990's

The Space Flight Operations Center (SFOC) is described with attention given to historical and technical aspects. The SFOC is designed to support each new JPL mission with all of its mission-unique processing as a ready adaptation of some set of baseline capabilities. Another goal of the SFOC is to allow the migration of current older JPL missions from their current systems that use aging and costly hardware and software to newer systems with similar functionality. Upon its completion, the planned support includes both downlink and uplink processing for a projected six mission set.

Gainsborough, A. J.↗

NASA Goddard Space Flight Center Robotic Processing System Program Automation Systems, volume 2

Topics related to robot operated materials processing in space (RoMPS) are presented in view graph form. Some of the areas covered include: (1) mission requirements; (2) automation management system; (3) Space Transportation System (STS) Hitchhicker Payload; (4) Spacecraft Command Language (SCL) scripts; (5) SCL software components; (6) RoMPS EasyLab Command & Variable summary for rack stations and annealer module; (7) support electronics assembly; (8) SCL uplink packet definition; (9) SC-4 EasyLab System Memory Map; (10) Servo Axis Control Logic Suppliers; and (11) annealing oven control subsystem.

Dobbs, M. E.↗

NASA Tech Briefs, June 2008

Topics covered include: Charge-Control Unit for Testing Lithium-Ion Cells; Measuring Positions of Objects Using Two or More Cameras; Lidar System for Airborne Measurement of Clouds and Aerosols; Radiation-Insensitive Inverse Majority Gates; Reduced-Order Kalman Filtering for Processing Relative Measurements; Spaceborne Processor Array; Instrumentation System Diagnoses a Thermocouple; Chromatic Modulator for a High-Resolution CCD or APS; Commercial Product Activation Using RFID; Cup Cylindrical Waveguide Antenna; Aerobraking Maneuver (ABM) Report Generator; ABM Drag_Pass Report Generator; Transformation of OODT CAS to Perform Larger Tasks; Visualization Component of Vehicle Health Decision Support System; Mars Reconnaissance Orbiter Uplink Analysis Tool; Problem Reporting System; G-Guidance Interface Design for Small Body Mission Simulation; DSN Scheduling Engine; Replacement Sequence of Events Generator; Force-Control Algorithm for Surface Sampling; Tool for Merging Proposals Into DSN Schedules; Micromachined Slits for Imaging Spectrometers; Fabricating Nanodots Using Lift-Off of a Nanopore Template; Making Complex Electrically Conductive Patterns on Cloth; Special Polymer/Carbon Composite Films for Detecting SO2; Nickel-Based Superalloy Resists Embrittlement by Hydrogen; Chemical Passivation of Li+-Conducting Solid Electrolytes; Organic/Inorganic Polymeric Composites for Heat-Transfer Reduction; Composite Cathodes for Dual-Rate Li-Ion Batteries; Improved Descent-Rate Limiting Mechanism; Alignment-Insensitive Lower-Cost Telescope Architecture; Micro-Resistojet for Small Satellites; Using Piezoelectric Devices to Transmit Power through Walls; Miniature Latching Valve; Apparatus for Sampling Surface Contamination; Novel Species of Non-Spore-Forming Bacteria; Chamber for Aerosol Deposition of Bioparticles; Hyperspectral Sun Photometer for Atmospheric Characterization and Vicarious Calibrations; Dynamic Stability and Gravitational Balancing of Multiple Extended Bodies; Simulation of Stochastic Processes by Coupled ODE-PDE; Cluster Inter-Spacecraft Communications; Genetic Algorithm Optimizes Q-LAW Control Parameters; Low-Impact Mating System for Docking Spacecraft; Non-Destructive Evaluation of Materials via Ultraviolet Spectroscopy; Gold-on-Polymer-Based Sensing Films for Detection of Organic and Inorganic Analytes in the Air; and Quantum-Inspired Maximizer.

Source record↗

Iris Deep-Space Transponder for SLS EM-1 CubeSat Missions

Several key design upgrades have been recently made to the Iris Deep-Space Transponder baselined to be used on secondary payload missions of the upcoming Space Launch System Exploration Mission One (SLS EM-1). The Iris Transponder is a reconfigurable software-defined radio (SDR) designed for missions requiring interoperability with NASA's Deep Space Network (DSN) on X-band frequencies (7.2 GHz uplink, 8.4 GHz downlink). The transponder provides radiometric tracking support with the DSN to provide navigational products for precise orbit determination while performing standard uplink and downlink communications in a CubeSat/SmallSat-applicable package size. The recent hardware changes include a volume reduction of 30% from previous models, with the main transponder unit weighing less than 1.0 kg, while maintaining total ionizing dose (TID) radiation tolerance of >23 krads (Si) for deep-space missions. Lab tests indicate maximum downlink rates of up to 6.25 Msps can be supported by the transponder in conventional BPSK modulation, but most SLS EM-1 CubeSat missions are link-performance limited to less than 256 kbps. A prototype unit of the flight production units has been assembled and various performance and characterization tests are underway. This talk discusses the key design aspects and specifications of the Iris Transponder and presents preliminary results from early testing of the assembled transponder.

Kobayashi, M. Michael↗

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗

NASA’s Deep Space Network (DSN) Lunar Exploration Upgrades (DLEU)

In the near future, the National Aeronautics and Space Administration (NASA) will returnhumansto the moon beginning the next era of human exploration. NASA’s Space Communications and Navigation (SCaN) program will play a vital role in establishing communications and navigation support to realize the ambitious goals of the Artemis program. SCaN’s overall lunar communications support plan will be covered in a separate 2023 SpaceOps paper: “NASA’s Communications and Navigation Architecture Plans to Support the Return to the Moon and a Sustainable Lunar Presence.” The four-point plan,as it currently stands, includes lunar relay services, a dedicated set of new ground stations, international partner contributions,and supportthrough the Deep Space Network (DSN)and associated upgrades. This paper will have a more granular focus on the DSN and NASA’s plans to upgrade and expand the network to be better suited for human spaceflight on and around the lunar surface. NASA’s Deep Space Network (DSN) will be a critical communications component for the upcoming lunar activities. There will be multiple spacecraft, using different bands, and some of those spacecraft will be transmitting and receiving using multiple bands, requiring DSN support of S-band (2 GHz), X-band (7 GHz up, 8 GHz down), and K-band (22.5 GHz up, 26 GHz down). Since there may be more than one spacecraft in the beamwidth of the DSN antennas, the DSN support will require an extension of the DSN’s capability to support multiple spacecraft using one antenna, expanding it to provide two simultaneous uplinks in the different bands at each antenna. Achieving this requires using new techniques for manufacturing the frequency selective surfaces, called dichroics, which steer the different frequency beams from and to the appropriate transmitting and receiving equipment, along with the addition of a new K-band uplink system. Additionally, due to the relative closeness of the moon from Earth (as opposed to the planetary missionsthe DSN supports daily), significantly higher data rates on both uplink and downlinkare requiredare possible and desirable by the lunar missions, specifically up to 20 Mbps on the uplink and 150 Mbps on the downlink, both using Low Density Parity Check (LDPC) error correcting codes. And, again due to the relative closeness of the moon, there is a need for low latency data delivery of the high rate downlink telemetry which requires a change in the current DSN paradigm of delivering higher rate data with higher latency.

Moon↗

NASA's Deep Space Network (DSN) Lunar Exploration Upgrades (DLEU)

In the near future, the National Aeronautics and Space Administration (NASA) will return to the moon beginning the next era of human exploration. NASA’s Space Communications and Navigation (SCaN) program will play a vital role in establishing communications and navigation support to realize the ambitious goals of the Artemis program. SCaN’s overall lunar communications support plan will be covered in a separate 2023 SpaceOps paper: “NASA’s Communications and Navigation Architecture Plans to Support the Return to the Moon and a Sustainable Lunar Presence”. The plan as it currently stands, includes a three-fold approach of lunar relay services, a dedicated set of new ground stations and support through the Deep Space Network (DSN). This paper will have a more granular focus on the DSN and NASA’s plans to upgrade and expand the network to be better suited for human spaceflight on and around the lunar surface. NASA’s Deep Space Network (DSN) will be a critical communications component for the upcoming lunar activities. There will be multiple spacecraft, using different bands, and some of those spacecraft will be transmitting and receiving using multiple bands, requiring DSN support of S-band (2 GHz), X-band (7 GHz up, 8 GHz down), and K-band (22.5 GHz up, 26 GHz down). Since there may be more than one spacecraft in the beamwidth of the DSN antennas, the DSN support will require an extension of the DSN’s capability to support multiple spacecraft using one antenna, expanding it to provide two simultaneous uplinks in the different bands at each antenna. Achieving this requires using new techniques for manufacturing the frequency selective surfaces, called dichroics, which steer the different frequency beams from and to the appropriate transmitting and receiving equipment, along with the addition of a new K-band uplink system. Additionally, due to the relative closeness of the moon from Earth (as opposed to the planetary missions the DSN supports daily), significantly higher data rates on both uplink and downlink are required, specifically up to 20 Mbps on the uplink and 150 Mbps on the downlink, both using Low Density Parity Check (LDPC) error correcting codes. And, again due to the relative closeness of the moon, there is a need for low latency data delivery of the high rate downlink telemetry which requires a change in the current DSN paradigm of delivering higher rate data with higher latency.

deep space network↗

The Deep Space Network's X/X/Ka Feed: Modifications for 100 kW CW Uplink Operation

The Deep Space Network, which provides communication services for NASA's robotic missions, consists of a number of 34m beam waveguide antennas and conventional 70m dual-reflector antennas located around the globe, [1]. The 34m beam waveguide antennas employ a three-band feed covering the deep space uplink band near 7.2 GHz, and downlink bands at 8.45 and 32 GHz. Simultaneous uplink commanding at 25 kW CW and ultra low noise reception in both bands is supported along with monopulse tracking at 32 GHz, [2]. An existing uplink capability of 25 kW is also available on the 70m antennas using a more conventional X/X diplexing feed. In order to provide an equivalent uplink capability with the 34m antennas the X/X/Ka feed is currently being modified for 100 kW CW operation, [3]. Here we will discuss both the existing feed and the 100 kW modifications which are underway.

Feed Uplink↗

Application and Operations Concepts of Large Transmit Phased Array of Parabolic Reflectors

The primary motive for large transmit array of parabolic reflectors, also known as Uplink Array, was to explore alternate methods in order to replace the large 70m antennas of Deep Space Network (DSN) such that the core capability for emergency support to a troubled spacecraft in deep space is preserved. Given that the Uplink Array is a new technology, the focus has always been on its feasibility and phase calibration techniques, which by itself is quite a challenge. It would be interesting to examine, however, what else could be accomplished by the Uplink Array capability other than the emergency support to a troubled spacecraft in deep space. ... The objective of this paper is to discuss a few application scenarios and the corresponding operation concepts, such as lunar positioning system, high EIRP uplink and the synergies with solar radar, and high power RF beams.

Uplink Array↗

A Multi-mission Event-Driven Component-Based System for Support of Flight Software Development, ATLO, and Operations first used by the Mars Science Laboratory (MSL) Project

This paper details an architectural description of the Mission Data Processing and Control System (MPCS), an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is developed based on a set of small reusable components, implemented in Java, each designed with a specific function and well-defined interfaces. An industry standard messaging bus is used to transfer information among system components. Components generate standard messages which are used to capture system information, as well as triggers to support the event-driven architecture of the system. Event-driven systems are highly desirable for processing high-rate telemetry (science and engineering) data, and for supporting automation for many mission operations processes.

Mission Data Processing and Control System (MPCS)↗

A Multi-mission Event-Driven Component-Based System for Support of Flight Software Development, ATLO, and Operations first used by the Mars Science Laboratory (MSL) Project

This viewgraph presentation reviews the architectural description of the Mission Data Processing and Control System (MPCS). MPCS is an event-driven, multi-mission ground data processing components providing uplink, downlink, and data management capabilities which will support the Mars Science Laboratory (MSL) project as its first target mission. MPCS is designed with these factors (1) Enabling plug and play architecture (2) MPCS has strong inheritance from GDS components that have been developed for other Flight Projects (MER, MRO, DAWN, MSAP), and are currently being used in operations and ATLO, and (3) MPCS components are Java-based, platform independent, and are designed to consume and produce XML-formatted data

Mission Data Processing and Control System (MPCS)↗