Engineering PapersSearch

SEARCH · Engineering Papers

Results for “ICD”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 73 records · Page 4

SOLON: An autonomous vehicle mission planner

The State-Operator Logic Machine (SOLON) Planner provides an architecture for effective real-time planning and replanning for an autonomous vehicle. The highlights of the system, which distinguish it from other AI-based planners that have been designed previously, are its hybrid application of state-driven control architecture and the use of both schematic representations and logic programming for the management of its knowledge base. SOLON is designed to provide multiple levels of planning for a single autonomous vehicle which is supplied with a skeletal, partially-specified mission plan at the outset of the vehicle's operations. This mission plan consists of a set of objectives, each of which will be decomposable by the planner into tasks. These tasks are themselves comparatively complex sets of actions which are executable by a conventional real-time control system which does not perform planning but which is capable of making adjustments or modifications to the provided tasks according to constraints and tolerances provided by the Planner. The current implementation of the SOLON is in the form of a real-time simulation of the Planner module of an Intelligent Vehicle Controller (IVC) on-board an autonomous underwater vehicle (AUV). The simulation is embedded within a larger simulator environment known as ICDS (Intelligent Controller Development System) operating on a Symbolics 3645/75 computer.

Dudziak, M. J.

Design Feasibility Study of a Space Station Freedom Truss

Here, the focus is on the design and configuration feasibility of the short spacer for the Space Station Program in its launch configuration. The product of this study is being used by Rockwell International (Rocketdyne Division) as they continue their design concept of the current short spacer configuration. It is anticipated that the launch loads will dominate the on-orbit loads and dictate the design configuration of the short spacer. At the present time, the on-orbit loads have not been generated. The structural analysis discussed herein is based on the transient events derived from the Space Transportation System (STS) Interface Control Document (ICD). The transient loading events consist of liftoff loads, landing loads, and emergency landing loads. The quasi-static loading events have been neglected, since the magnitude of the acceleration factors are lower than the transient acceleration factors. The normal mode analyses presented herein are based on the most feasible configurations with acceptable stress ranges.

Armand, Sasan C.

Longitudinal study of astronaut health: Mortality in the years 1959-1991

We conducted a historical cohort study of mortality among 195 astronauts who were exposed to space and medical sources of radiation between 1959 and 1991. Cumulative occupational and medical radiation exposures were obtained from the astronaut radiation exposure history data base. Causes of death were obtained from obligatory death certificates and autopsy reports that were on file in the medical records. A total of 18 deaths occurred during the 32-year follow-up period for which the all-cause standardized mortality ratio (SMR) was 142 (95 percent confidence interval 84 225). There was one cancer death in the buccal cavity and pharynegeal ICD-9 rubric whose occurrence was significantly beyond expectation. Mortality for coronary disease was 59 percent lower than expected (2 deaths; SMR = 41; 95 percent confidence limit 5 147). The crude death rate for 10 occupationally related accidents was 400 deaths per 100,000 person-years, which is an order of magnitude greater than accidental death rates in mining industries. The SMR of 1027 for fatal accidents was significantly beyond expectation (14 deaths; 95 percent confidence limit 561 1723) and was similar to SMRs for accidents among aerial pesticide applications. The 10-year cumulative risk of occupational fatalities based on the exponential, Weibull, Gompertz, and linear-exponential distributions was 10 percent. Mortality from motor vehicle accidents was slightly higher than expected but was not significant (1 death; SMR = 145; 95 percent confidence limit 2 808). Radiation exposures from medical procedures accounted for a majority of cumulative dose when compared with space radiation exposures. The results of the study do not confirm the impression that astronauts are at increased risk of cancer, but this does not obviate the need for further study. Overall, it was found that astronauts are at a health disadvantage as a result of catastrophic accidents.

Peterson, Leif E.

Structural design feasibility study of Space Station long spacer truss

The structural design and configuration feasibility of the long spacer truss assembly that will be used as part of the Space Station Freedom is the focus of this study. The structural analysis discussed herein is derived from the transient loading events presented in the Space Transportation System Interface Control Document (STS ICD). The transient loading events are liftoff, landing, and emergency landing loads. Quasi-static loading events were neglected in this study since the magnitude of the quasi-static acceleration factors is lower than that of the transient acceleration factors. Structural analysis of the proposed configuration of the long spacer truss with four longerons indicated that negative safety margins are possible. As a result, configuration changes were proposed. The primary configuration change suggested was to increase the number of truss longerons to six. The six-longeron truss appears to be a more promising structure than the four-longeron truss because it offers a positive margin of safety and more volume in its second bay (BAY2). This additional volume can be used for resupply of some of the orbital replacement units (such as a battery box). Note that the design effort on the long spacer truss has not fully begun and that calculations and reports of the negative safety margins are, to date, based on concept only.

Armand, Sasan C.

Earth Observing System (EOS) Advanced Microwave Sounding Unit-A (AMSU-A): Instrumentation interface control document

This Interface Control Document (ICD) defines the specific details of the complete accomodation information between the Earth Observing System (EOS) PM Spacecraft and the Advanced Microwave Sounding Unit (AMSU-A)Instrument. This is the first submittal of the ICN: it will be updated periodically throughout the life of the program. The next update is planned prior to Critical Design Review (CDR).

Source record

Microgravity Acceleration Measurement System (MAMS) Flight Configuration Verification and Status

The Microgravity Acceleration Measurement System (MAMS) is a precision spaceflight instrument designed to measure and characterize the microgravity environment existing in the US Lab Module of the International Space Station. Both vibratory and quasi-steady triaxial acceleration data are acquired and provided to an Ethernet data link. The MAMS Double Mid-Deck Locker (DMDL) EXPRESS Rack payload meets all the ISS IDD and ICD interface requirements as discussed in the paper which also presents flight configuration illustrations. The overall MAMS sensor and data acquisition performance and verification data are presented in addition to a discussion of the Command and Data Handling features implemented via the ISS, downlink and the GRC Telescience Center displays.

Wagar, William

Standards-and Component-Based Mission Operations Architecture at NASA's Goddard Space Flight Center

NASA Goddard Space Flight Center (GSFC) manages many of NASA s earth and space science satellite missions. A wide variety of commercial products and GSFC-developed software components are typically integrated into a unique system configuration for each mission. Independent development of the many mission operations center systems has led to systems that are expensive to integrate, difficult to infuse with new capabilities developed for other programs, and cumbersome to maintain. This traditional approach becomes even more problematic as NASA moves towards satellite constellations, new operations concepts, and even further budgets reductions. The GSFC Mission Services Evolution Center (GMSEC) is creating a new architecture for future missions at GSFC. Instead of selecting the best-in-class components and creating a standard control center system, GMSEC is developing component interface standards so that multiple products can plug-and-play into the configuration. Missions can then select the best components based on the merits of the product and not simply based on recent integration history at NASA. The GMSEC system utilizes a publish/subscribe information bus and standard XML-based key message interfaces. Functional components can either match directly to the interface standard, or adapters can be developed to match the product's interface to the GMSEC standard with out impacting the source product. Applications Program Interfaces (API's) are being developed to isolate the underlying middleware from the applications software and to allow the middleware product to be switched if necessary. Interface Control Documents (ICDs) between each pair of communicating components is replaced by a single message/API specification document. New applications must simply match to the information bus standards and need not worry about all of the other applications in the system. For legacy software, adapters can be developed to facilitate communications between the application and the information bus. As the approach has matured, it has become apparent that it can provide innovative solutions to some of the multi-satellite challenges facing GSFC.

Smith, Danford

SpaceWire Protocol ID: What Does It Mean To You?

Spacewire is becoming a popular solution for satellite high-speed data buses because it is a simple standard that provides great flexibility for a wide range of system requirements. It is simple in packet format and protocol, allowing users to easily tailor their implementation for their specific application. Some of the attractive aspects of Spacewire that make it easy to implement also make it hard for future reuse. Protocol reuse is difficult because Spacewire does not have a defined mechanism to communicate with the higher layers of the protocol stack. This has forced users of Spacewire to define unique packet formats and define how these packets are to be processed. Each mission writes their own Interface Control Document (ICD) and tailors Spacewire for their specific requirements making reuse difficult. Part of the reason for this habit may be because engineers typically optimize designs for their own requirements in the absence of a standard. This is an inefficient use of project resources and costs more to develop missions. A new packet format for Spacewire has been defined as a solution for this problem. This new packet format is a compliment to the Spacewire standard that will support protocol development upon Spacewire. The new packet definition does not replace the current packet structure, i.e., does not make the standard obsolete, but merely extends the standard for those who want to develop protocols over Spacewire. The Spacewire packet is defined with the first part being the Destination Address, which may be one or more bytes. This is followed by the packet cargo, which is user defined. The cargo is truncated with an End-Of-Packet (EOP) marker. This packet structure offers low packet overhead and allows the user to define how the contents are to be formatted. It also provides for many different addressing schemes, which provide flexibility in the system. This packet flexibility is typically an attractive part of the Spacewire. The new extended packet format adds one new field to the packet that greatly enhances the capability of Spacewire. This new field called the Protocol Identifier (ID) is used to identify the packet contents and the associated processing for the packet. This feature along with the restriction in the packet format that uses the Protocol ID, allows a deterministic method of decoding packets that was not before possible. The first part of the packet is still the Destination Address, which still conforms to the original standard but with one restriction. The restriction is that the first byte seen at the destination by the user needs to be a logical address, independent of the addressing scheme used. The second field is defined as the Protocol ID, which is usually one byte in length. The packet cargo (user defined) follows the Protocol ID. After the packet cargo is the EOP, which defines the end of packet. The value of the Protocol ID is assigned by the Spacewire working group and the protocol description published for others to use. The development of Protocols for Spacewire is currently the area of greatest activity by the Spacewire working group. The first protocol definition by the working group has been completed and is now in the process of formal standardization. There are many other protocols in development for missions that have not yet received formal Protocol ID assignment, but even if the protocols are not formally assigned a value, this effort will provide synergism for future developments.

Rakow, Glenn

Control of Technology Transfer at JPL

Controlled Technology: 1) Design: preliminary or critical design data, schematics, technical flow charts, SNV code/diagnostics, logic flow diagrams, wirelist, ICDs, detailed specifications or requirements. 2) Development: constraints, computations, configurations, technical analyses, acceptance criteria, anomaly resolution, detailed test plans, detailed technical proposals. 3) Production: process or how-to: assemble, operated, repair, maintain, modify. 4) Manufacturing: technical instructions, specific parts, specific materials, specific qualities, specific processes, specific flow. 5) Operations: how-to operate, contingency or standard operating plans, Ops handbooks. 6) Repair: repair instructions, troubleshooting schemes, detailed schematics. 7) Test: specific procedures, data, analysis, detailed test plan and retest plans, detailed anomaly resolutions, detailed failure causes and corrective actions, troubleshooting, trended test data, flight readiness data. 8) Maintenance: maintenance schedules and plans, methods for regular upkeep, overhaul instructions. 9) Modification: modification instructions, upgrades kit parts, including software

Jet Propulsion Laboratory (JPL)

Injury Surveillance Among NASA Astronauts Using the Barell Injury Diagnosis Matrix

Astronauts perform physically demanding tasks and risk incurring musculoskeletal injuries during both groundbased training and missions. Increased injury rates throughout the history of the U.S. space program have been attributed to numerous factors, including an aging astronaut corps, increased Weightless Environment Training Facility (WETF) and Neutral Buoyancy Laboratory (NBL) training to construct the International Space Station, and improved clinical operations that promote injury prevention and reporting. With NASA program changes through the years (including retirement of the Shuttle program) and an improved training environment (including a new astronaut gym), there is no surveillance program to systematically track injury rates. A limited number of research projects have been conducted over the past 20 years to evaluate musculoskeletal injuries: (1) to evaluate orthopedic injuries from 1987 to 1995, (2) to describe upper extremity injuries, (3) to evaluate EVA spacesuit training related injuries, and (4) to evaluate in-flight musculoskeletal injuries. Nevertheless, there has been no consistently performed comprehensive assessment of musculoskeletal injuries among astronauts. The Barell Injury Diagnosis Matrix was introduced at the 2001 meeting of the International Collaborative Effort (ICE) on Injury Statistics. The Matrix proposes a standardized method of classifying body region by nature of injury. Diagnoses are coded using the International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM) coding system. The purpose of this study is to assess the usefulness and complexity of the Barell Injury Diagnosis Matrix to classify and track musculoskeletal injuries among NASA astronauts.

Murray, J. D.

Interfacing and Verifying ALHAT Safe Precision Landing Systems with the Morpheus Vehicle

The NASA Autonomous precision Landing and Hazard Avoidance Technology (ALHAT) project developed a suite of prototype sensors to enable autonomous and safe precision landing of robotic or crewed vehicles under any terrain lighting conditions. Development of the ALHAT sensor suite was a cross-NASA effort, culminating in integration and testing on-board a variety of terrestrial vehicles toward infusion into future spaceflight applications. Terrestrial tests were conducted on specialized test gantries, moving trucks, helicopter flights, and a flight test onboard the NASA Morpheus free-flying, rocket-propulsive flight-test vehicle. To accomplish these tests, a tedious integration process was developed and followed, which included both command and telemetry interfacing, as well as sensor alignment and calibration verification to ensure valid test data to analyze ALHAT and Guidance, Navigation and Control (GNC) performance. This was especially true for the flight test campaign of ALHAT onboard Morpheus. For interfacing of ALHAT sensors to the Morpheus flight system, an adaptable command and telemetry architecture was developed to allow for the evolution of per-sensor Interface Control Design/Documents (ICDs). Additionally, individual-sensor and on-vehicle verification testing was developed to ensure functional operation of the ALHAT sensors onboard the vehicle, as well as precision-measurement validity for each ALHAT sensor when integrated within the Morpheus GNC system. This paper provides some insight into the interface development and the integrated-systems verification that were a part of the build-up toward success of the ALHAT and Morpheus flight test campaigns in 2014. These campaigns provided valuable performance data that is refining the path toward spaceflight infusion of the ALHAT sensor suite.

Carson, John M., III

Modeling Complex Cross-Systems Software Interfaces Using SysML

The complex flight and ground systems for NASA human space exploration are designed, built, operated and managed as separate programs and projects. However, each system relies on one or more of the other systems in order to accomplish specific mission objectives, creating a complex, tightly coupled architecture. Thus, there is a fundamental need to understand how each system interacts with the other. To determine if a model-based system engineering approach could be utilized to assist with understanding the complex system interactions, the NASA Engineering and Safety Center (NESC) sponsored a task to develop an approach for performing cross-system behavior modeling. This paper presents the results of applying Model Based Systems Engineering (MBSE) principles using the System Modeling Language (SysML) to define cross-system behaviors and how they map to crosssystem software interfaces documented in system-level Interface Control Documents (ICDs).

Earth orbit

A Tailored Concept of Operations for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this project is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services.

Systems

Getting to the Heart of Cardiovascular Risk Assessment in Astronauts for Exploration Class Missions

Since the beginning of manned spaceflight, NASA has recognized the potential risk of cardiovascular decrements due to stressors in the space environment. Of particular concern is the effect of space radiation on cardiovascular disease since astronauts will be exposed to higher levels of galactic cosmic rays outside the Earth's protective magnetosphere. To date, only a few studies have examined the effects of heavy ion radiation on cardiovascular disease, and at lower, space-relevant doses, the association between radiation exposure and cardiovascular pathology is more varied and unclear. Furthermore, other spaceflight conditions such as microgravity, circadian shifts, and confinement stress pose unique challenges in estimating the health risks that can be attributed to exposure to ionizing radiations. In this work, we review age, cause of mortality, and radiation exposure amongst early NASA astronauts in selection groups and discuss the limitations of assessing such a cohort when attempting to characterize the risk of space flight, including stressors such as space radiation and microgravity exposure, on cardiovascular health. METHODS: NASA astronauts in selection groups 1-7 were chosen and the comparison population was white men of the same birth cohort as drawn from data from the CDC Wonder Database and CDC National Center for Health Statistics Life Tables. Cause of death information was obtained from the Lifetime Surveillance of Astronaut Health program and deceased astronauts were classified based on ICD-10 codes: ischemic heart disease (IHD), stroke, cancer, acute occupational events, non-NASA accidents, and other/unknown. Expected years of life left and expected age at death were calculated for the cohort. RESULTS AND CONCLUSIONS: There were 32 deaths in this early astronaut population, 12 of which were due to accidents or acute occupational events that impacted lifespan considerably. The average age at death from these causes is 30 years lower than the average expected ~70 years of age in the general population. Remarkably, all 41 living early astronauts outlived our calculated expected age at death for members of their birth cohort; furthermore, 13 of the 20 deceased astronauts who did not die in NASA/non-NASA accidents exceeded this age. There was no difference in IHD between the astronaut cohort and the comparison population; therefore, it is not possible to associate IHD mortality with radiation in that astronaut cohort. As NASA looks toward future exploration-class missions, early astronaut cohorts provide a convenient option for assessing these risks and for developing mitigation strategies. However, many challenges still exist when assessing such limited evidence, including small cohort size, health and lifestyle confounders (such as smoking and drinking), the high accident mortality rate, and the fact that many of these astronauts are still alive, outliving many of their birth-cohort peers. Future analysis should include a longitudinal study, monitoring cases as they occur in the cohort. As this cohort is currently followed-up over time, and as more IHD cases are anticipated in a population of this age, this type of study is not as resource-intensive as would normally be the case.

Elgart, S. R.

Tailoring a ConOps for NASA LSP Integrated Operations

An integral part of the Systems Engineering process is the creation of a Concept of Operations (ConOps) for a given system, with the ConOps initially established early in the system design process and evolved as the system definition and design matures. As Integration Engineers in NASA's Launch Services Program (LSP) at Kennedy Space Center (KSC), our job is to manage the interface requirements for all the robotic space missions that come to our Program for a Launch Service. LSP procures and manages a launch service from one of our many commercial Launch Vehicle Contractors (LVCs) and these commercial companies are then responsible for developing the Interface Control Document (ICD), the verification of the requirements in that document, and all the services pertaining to integrating the spacecraft and launching it into orbit. However, one of the systems engineering tools that have not been employed within LSP to date is a Concept of Operations. The goal of this paper is to research the format and content that goes into these various aerospace industry ConOps and tailor the format and content into template form, so the template may be used as an engineering tool for spacecraft integration with future LSP procured launch services. This tailoring effort was performed as the authors final Masters Project in the Spring of 2016 for the Stevens Institute of Technology and modified for publication with INCOSE (Owens, 2016).

Knowledge

Cardiovascular Disease Outcomes Among the NASA Astronaut Corps

BACKGROUND: Acute effects of spaceflight on the cardiovascular system have been studied extensively, but the combined chronic effects of spaceflight and aging are not well understood. Preparation for and participation in spaceflight activities are associated with changes in the cardiovascular system such as decreased carotid artery distensibility and decreased ventricular mass which may lead to an increased risk of cardiovascular disease. Additionally, astronauts who travel into space multiple times or for longer durations may be at an increased risk across their lifespan. To that end, the purpose of this study was to determine the incidence of common cardiovascular disease (CVD) outcomes among the NASA astronaut corps during their active career and through retirement. METHODS: Cardiovascular disease outcomes were defined as reports of any of the following: myocardial infarction (MI), revascularization procedures (coronary artery bypass graft surgery [CABG] or percutaneous coronary intervention [PCI]), hypertension, stroke or transient ischemic attack [TIA], heart failure, or total CVD (as defined by the AHA - combined outcome of MI, Angina Pectoris, heart failure, stroke, and hypertension). Each outcome was identified individually from review of NASA's Electronic Medical Record (EMR), EKG reports, and death certificates using ICD-9 codes as well as string searches of physician notes of astronaut exams that occurred between 1959 and 2016. RESULTS: Of 338 NASA astronauts selected as of 2016, 9 reported an MI, 12 reported a revascularization procedure, (7 PCI and 5 CABG), 4 reported Angina (without MI), 5 reported heart failure, 9 reported stroke/TIA, and 96 reported hypertension. Total CVD was reported in 105 astronauts. No astronaut who had an MI or revascularization procedure flew a spaceflight mission following the event. All MI, revascularization, and stroke events occurred in male astronauts. When reviewing astronaut ECG reports, abnormal ECG reports were found in only 8% of records (n=430) and mainly among retired astronauts (82%), with marked sinus bradycardia being the reason for the abnormal classification.

Charvat, Jacqueline M.

Validation & Verification of Electrical Components B2 Test Facility

The research focus of this project is to assist in the closure of Measurement, Monitoring and Control System (MMCS) and other electrical requirements in support of the B2 Space Launch System (SLS) Core Stage Green Run Test Project. Alongside this goal I am to understand project management tools to analyze and control activities/tasks associated with those items. The project I am working on will assist electrical engineers in developing and or identifying closure rationale for the MMCS and electrical requirements. Also as serving the role of a training project manager, I am to develop and maintain a method for tracking progress with estimate completion dates specifically identifying those items during this performance window. The methods I used in order to perform the research consisted of worddocuments, excel sheets, and pdf documents needed for review. For example, documents consisted of: a SLS Core Stage Green Run Facility Requirement Document (FRD) identifying the SSC MMCS and electrical requirements, a Stage Controller to SSC Interface Control Document (ICD) identifying the SSC requirements, and the B2 SLS Core Stage Green Run Test project System Requirements Document (SRD) which identifies the MMCS and electrical requirements. The files were sent to me by both mentors, Mr. Barry Robinson and Ms. Dawn Davis. Overall, the review process for the word documents and excel spreadsheets proved to be successful. The data for the electrical components were accurate and were consistent with the original recorded data. However, the consistency with the pdf documents did not follow up all the way. Attention to this mistake was made and further revisions were done in order for the data to agree with each other. Furthermore, an itinerary was designed using Microsoft Outlook in order to track progress with estimated completion dates. This project contributes to NASA/Center Missions and Goals through the Waterfall Model. The Waterfall Model is a linear system used for engineering design. In the Waterfall Model, the fourth step is Verification and Validation. This involves installation, testing, and debugging of the B2 SLS Core Stage electrical components. For the SLS Core Stage Green Run Test Project, each requirement contained in this approved requirements set will have at least one Verification Item (VI) assigned to it. During the design phase, VIs will mostly consist of Analysis or Inspection types. Design phase VIs and closure information will be documented in Dynamics Data Management System (DDMS) in the form of analysis reports and design documentation.

Bastian, Tyler

Risk-Reduction Autonomy Implementation to Enable NASA Artemis Missions

To achieve NASA’s Artemis program mission objectives a high level of autonomy and ubiquitous autonomy throughout the systems that are being developed will be necessary. The autonomous systems of Artemis will require a distributed autonomy capability, with autonomous systems organized functionally in a hierarchical architecture, where systems at higher levels of the hierarchy have authority over systems at lower levels. The challenge of developing autonomy technologies and concepts of operations for Artemis has been undertaken by the NASA Gateway Working Group. This group has developed requirements, architectures, concepts of operations, and interface control documents, in the context of a hierarchical distributed architecture that includes the following: a Vehicle System Manager (VSM) that autonomously manages the entire Gateway; Module System Managers (MSMs) that autonomously manage each module; and System Managers (SMs) that autonomously manage systems within a module(i.e. ECLSS).A substantially high level of autonomy needs to be achieved by each element of the hierarchy (VSM, MSM, SM)to meet requirements for uncrewed operations; this includes conditions that will have minimal and/or delayed ground intervention (i.e. requirements for sustainability for months of operation without crew or ground support). To advance an implementation of this autonomy design (Gateway Autonomy Design –GAD), a collaboration was established between the Autonomous Systems Laboratory (ASL) at NASA Stennis Space Center and Lockheed Martin. The objectives of this partnership were the following: (1)to implement autonomy at the VSM, MSM, and SM levels;(2) to implement communications among a VSM, 2 MSMs, ORION (a visiting vehicle somewhat equivalent to a module) and 1 SM (a power system), and (3) test autonomous operations with representative use cases. A SM backed by a high-fidelity simulation was created to facilitate demonstrations of use cases that originated in a system of a module. Communication between the VSM and MSMs was implemented according to Concepts of Operations and Interface Control Documents (ICDs). Demonstrations were conducted to address nominal and off-nominal operations and multi-module interactions with VSM. Additionally, user interfaces were created to provide awareness about ongoing processes and results while enhancing the demonstration. Demonstrations included the following use cases: (1)Orion as visiting vehicle registers with VSM;(2) VSM reschedules a module’s timelines when another module’s MSM task fails; and (3) a module’s Power System Manager (PSM) standalone demonstration that included component failure diagnostics, tracing component failure to effected components, which in turn, reports failure information up to the VSM for acknowledgement and display. This paper will describe the detailed technology and autonomous systems developed, and the integrated multi-module demonstrations conducted. Also, challenges that must be met to fully implement the GAD defined by Gateway will be addressed.

Autonomous Systems