CCSDS Spacecraft Uplink Protocol in a Space-Qualified ASIC
This paper describes the capabilities of the Hardware Command Decode (HCD) application specific integrated circuit (ASIC) developed for the Cassini spacecraft.
SEARCH · Search NASA
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.
This paper describes the capabilities of the Hardware Command Decode (HCD) application specific integrated circuit (ASIC) developed for the Cassini spacecraft.
Closed loop, feedback verification techniques for command system of unmanned scientific satellite
Spacecraft manual for OSO - telemetry system, command system, power supply and distribution, antenna system, experiment complement, temperature monitoring, and launch program
Heat studies with the highly resistant bacterial spore isolated from Cape Kennedy soil were continued, and the D130C was determined. The interior surfaces of the command module of the Apollo 17 spacecraft were studied for microbial contamination during assembly and testing. The thermal resistance of naturally occurring airborne bacterial spores was determined, using the heating times of 2, 4, 6, and 8 hr. at 125 C. The evaluation of a terminal sterilization process for unmanned lander spacecraft is also continuing.
An instrument system to acquire attitude determination data for the RAE-B spacecraft was designed and built. The system consists of an electronics module and two optical scanner heads. Each scanner head has an optical scanner with a field of view of 0.7 degrees diameter which scans the sky and measures the position of the moon, earth and sun relative to the spacecraft. This scanning is accomplished in either of two modes. When the spacecraft is spinning, the scanner operates in spherical mode, with the spacecraft spin providing the slow sweep of lattitude to scan the entire sky. After the spacecraft is placed in lunar orbit and despun, the scanner will operate in planar mode, advancing at a rate of 5.12 seconds per revolution in a fixed plane parallel to the spacecraft Z axis. This scan will cross and measure the moon horizons with every revolution. Each scanner head also has a sun slit which is aligned parallel to the spin axis of the spacecraft and which provides a sun pulse each revolution of the spacecraft. The electronics module provides the command and control, data processing and housekeeping functions.
The primary objective of the Spacecraft Attitude Precision Pointing and Slewing Adaptive Control (SAPPSAC) experiment is to establish feasibility and evaluate capabilities of a ground-based spacecraft attitude control system, wherein RF command and telemetry links, together with a ground station on-line minicomputer, perform closed loop attitude control of the Applications Technology Satellite-6 (ATS-6). The ground processor is described, including operational characteristics and the controller software. Attitude maneuvers include precision pointing to fixed targets, slewing between targets, and generation of prescribed ground tracks. Test results show high performance and reliability for over 30 hours of on-line control with no serious anomalies. Attitude stabilization relative to a prescribed target has been achieved to better than 0.007 deg in pitch and roll and 0.02 deg in yaw for a period of 43 min. Ground tracks were generated which had maximum latitude/longitude deviations less than 0.15 deg from reference.
The Deep Space Network (DSN) support of Viking spacecraft activities and the DSN Viking command and tracking support are reported. The status of DSN Mark 3 data (MDS) subsystem implementation project related Viking testing is included.
An engineering evaluation of the Multimission Modular Spacecraft power supply is presented. The spacecraft has one charger with eight commandable voltage versus temperature levels. Graphs are presented which represent: (1) cell voltage limits vs. temperature; (2) charge ratio vs. temperature; (3) effect of 0.0 percent impedance unbalance at 10 C; (4) shorted cell at 10 C; and (5) discharge voltage profile at 10 C.
The software design and documentation language (SDDL) is a general purpose processor to support a lanugage for the description of any system, structure, concept, or procedure that may be presented from the viewpoint of a collection of hierarchical entities linked together by means of binary connections. The language comprises a set of rules of syntax, primitive construct classes (module, block, and module invocation), and language control directives. The result is a language with a fixed grammar, variable alphabet and punctuation, and an extendable vocabulary. The application of SDDL to the detailed software design of the Command Data Subsystem for the Galileo Spacecraft is discussed. A set of constructs was developed and applied. These constructs are evaluated and examples of their application are considered.
The attitude control objectives of solar maximum mission are to point the boresight of the payload fine pointing sun sensor (FPSS) to any point within 30 arc-minutes of the Sun's center with an accuracy of 5 arc-seconds (3 sigma, pitch and yaw) and a jitter of less than 3 arc-seconds (3 sigma). To meet these stringent accuracy requirements, a procedure was developed for in-flight calibration of the FPSS. The spacecraft was maneuvered using FPSS offset commands to position the Sun at different points within the FPSS field of view. The coefficients of the FPSS digital to analog nonlinear transfer function were determined by minimizing the residuals between the pitch and yaw angles computed from the FPSS measurements and the corresponding reference angles obtained from inertial reference unit measurements. The actual in-flight calibration and the calibration algorithm are discussed.
An integrated hardware/software fault tolerant system for an earth oriented, computer controlled spacecraft is described. The design philosophy as well as the rationale behind the chosen fault tolerant system is outlined. In-flight performance of the system is included for several different instances where the Failure Detection and Correction system acted autonomously to protect the spacecraft. This system exceeded the expectations of the designers by demonstrating the capability to provide a measure of safety to the spacecraft for inadvertent and undesirable ground commands as well as satisfying its primary function of monitoring the flight hardware and software for failures.
The large antennas of the DSN support reception of low power telemetry signals from spacecraft (S/C), transmission of high power commands to S/C, and navigation of S/C by precision radiometric data. The specification and design of antennas were driven by the requirement to support those functions with high reliability. The number of antennas required in the DSN is determined by the number of S/C to be supported and their level of activity. A given size antenna aperture can be realized with a single element or by arraying smaller elements with the same total area. That approach can be applied to meeting many DSN requirements. There is a cost vs capability trade-off in arrayed vs single element designs. The operating microwave frequency is an important parameter for the antenna. Major radio astronomy antennas can be arrayed with DSN antennas to increase reception capability. The specification, design, and development of DSN antennas are examined.
As a spacecraft performs its mission, various loads are connected to the spacecraft power bus in response to commands from an on board computer, a function called power distribution. For the Mariner Mark II set of planetary missions, the power bus is 30 volts dc and when loads are connected or disconnected, both the bus and power return side must be switched. In addition, the power distribution function must be immune to single point failures and, when power is first applied, all switches must be in a known state. Traditionally, these requirements have been met by electromechanical latching relays. This paper describes a solid state switch which not only satisfies the requirements but incorporates several additional features including soft turn on, programmable current trip point with noise immunity, instantaneous current limiting, and direct telemetry of load currents and switch status. A breadboard of the design has been constructed and some initial test results are included.
This paper will present the current concept using extensible Markup Language (XML) as the underlying structure for the James Webb Space Telescope (JWST) database. The purpose of using XML is to provide a JWST database, independent of any portion of the ground system, yet still compatible with the various systems using a variety of different structures. The testing of the JWST Flight Software (FSW) started in 2002, yet the launch is scheduled for 2011 with a planned 5-year mission and a 5-year follow on option. The initial database and ground system elements, including the commands, telemetry, and ground system tools will be used for 19 years, plus post mission activities. During the Integration and Test (I&T) phases of the JWST development, 24 distinct laboratories, each geographically dispersed, will have local database tools with an XML database. Each of these laboratories database tools will be used for the exporting and importing of data both locally and to a central database system, inputting data to the database certification process, and providing various reports. A centralized certified database repository will be maintained by the Space Telescope Science Institute (STScI), in Baltimore, Maryland, USA. One of the challenges for the database is to be flexible enough to allow for the upgrade, addition or changing of individual items without effecting the entire ground system. Also, using XML should allow for the altering of the import and export formats needed by the various elements, tracking the verification/validation of each database item, allow many organizations to provide database inputs, and the merging of the many existing database processes into one central database structure throughout the JWST program. Many National Aeronautics and Space Administration (NASA) projects have attempted to take advantage of open source and commercial technology. Often this causes a greater reliance on the use of Commercial-Off-The-Shelf (COTS), which is often limiting. In our review of the database requirements and the COTS software available, only very expensive COTS software will meet 90% of requirements. Even with the high projected initial cost of COTS, the development and support for custom code over the 19-year mission period was forecasted to be higher than the total licensing costs. A group did look at reusing existing database tools and formats. If the JWST database was already in a mature state, the reuse made sense, but with the database still needing to handing the addition of different types of command and telemetry structures, defining new spacecraft systems, accept input and export to systems which has not been defined yet, XML provided the flexibility desired. It remains to be determined whether the XML database will reduce the over all cost for the JWST mission.
The Mars Global Surveyor (MGS) mission will return to Mars to re- cover most of the science lost when the ill fated Mars Observer space- craft suffered a catastrophic anomaly in its propulsion system and did not go into orbit. Described in detail are the methods employed by the MGS Sequence Team to accelerate science command processing by using standard command generation process and standard UNIX control scripts.
The Deep Space Network (DSN) has three communication facilities which handle telemetry, commands, and other data relating to spacecraft missions. The network requires these three sites to share data with each other and with the Jet Propulsion Laboratory for processing and distribution. Many database management systems have replication capabilities built in, which means that data updates made at one location will be automatically propagated to other locations. This project examines multiple replication solutions, looking for stability, automation, flexibility, performance, and cost. After comparing these features, Oracle Streams is chosen for closer analysis. Two Streams environments are configured - one with a Master/Slave architecture, in which a single server is the source for all data updates, and the second with a Multi-Master architecture, in which updates originating from any of the servers will be propagated to all of the others. These environments are tested for data type support, conflict resolution, performance, changes to the data structure, and behavior during and after network or server outages. Through this experimentation, it is determined which requirements of the DSN can be met by Oracle Streams and which cannot.
Jet Propulsion Laboratory uses multi-mission software produced by the Mission Planning and Sequencing (MPS) team to process, simulate, translate, and package the commands that are sent to a spacecraft. MPS works under the auspices of the Multi-Mission Ground Systems and Services (MGSS). This software consists of nineteen applications that are in maintenance. The MPS software is classified as either class B (mission critical) or class C (mission important). The scheduling of tasks is difficult because mission needs must be addressed prior to performing any other tasks and those needs often spring up unexpectedly. Keeping track of the tasks that everyone is working on is also difficult because each person is working on a different software component. Recently the group adopted the Scrum methodology for planning and scheduling tasks. Scrum is one of the newer methodologies typically used in agile development. In the Scrum development environment, teams pick their tasks that are to be completed within a sprint based on priority. The team specifies the sprint length usually a month or less. Scrum is typically used for new development of one application. In the Scrum methodology there is a scrum master who is a facilitator who tries to make sure that everything moves smoothly, a product owner who represents the user(s) of the software and the team. MPS is not the traditional environment for the Scrum methodology. MPS has many software applications in maintenance, team members who are working on disparate applications, many users, and is interruptible based on mission needs, issues and requirements. In order to use scrum, the methodology needed adaptation to MPS. Scrum was chosen because it is adaptable. This paper is about the development of the process for using scrum, a new development methodology, with a team that works on disparate interruptible tasks on multiple software applications.
In today's rapidly advancing technology roadmap for space applications there is an emphasis on completing missions faster and cheaper than previous large-scale missions at the National Aeronautics and Space Administration (NASA) such as the Magnetospheric Multiscale (MMS) mission. As part of this effort, focus has shifted from using mostly radiation-tolerant or radiation-hardened parts to more commercial-off-the-shelf (COTS) components for missions that can last at least one year in orbit. However, there are some portions of a spacecraft's avionics, such as the command and data handling (C&DH) system and the Electrical Power Systems (EPS) that need to have some level of predictable reliability that goes beyond the capabilities of currently available COTS parts. While there are a number of COTS components that can withstand a total ionizing dose (TID) of tens or hundreds of kilorads, there is still a great deal of concern about tolerance to and mitigation of single-event effects (SEE).