Search NASA⌕ Search

SEARCH · Search NASA

Results for “staffing”

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 253 records · Page 14
All sourcesNASA NTRSDOE OSTI
NASA NTRS2014

Using AUTORAD for Cassini File Uplinks: Incorporating Automated Commanding into Mission Operations

As the Cassini spacecraft embarked on the Solstice Mission in October 2010, the flight operations team faced a significant challenge in planning and executing the continuing tour of the Saturnian system. Faced with budget cuts that reduced the science and engineering staff by over a third in size, new and streamlined processes had to be developed to allow the Cassini mission to maintain a high level of science data return with a lower amount of available resources while still minimizing the risk. Automation was deemed an important key in enabling mission operations with reduced workforce and the Cassini flight team has made this goal a priority for the Solstice Mission. The operations team learned about a utility called AUTORAD which would give the flight operations team the ability to program selected command files for radiation up to seven days in advance and help minimize the need for off-shift support that could deplete available staffing during the prime shift hours. This paper will describe how AUTORAD is being utilized by the Cassini flight operations team and the processes that were developed or modified to ensure that proper oversight and verification is maintained in the generation and execution of radiated command files.

Goo, Sherwin↗
NASA NTRS2017

Smashing the Stovepipe: Leveraging the GMSEC Open Architecture and Advanced IT Automation to Rapidly Prototype, Develop and Deploy Next-Generation Multi-Mission Ground Systems

Satellite/Payload Ground Systems - Typically highly-customized to a specific mission's use cases - Utilize hundreds (or thousands!) of specialized point-to-point interfaces for data flows / file transfers Documentation and tracking of these complex interfaces requires extensive time to develop and extremely high staffing costs Implementation and testing of these interfaces are even more cost-prohibitive, and documentation often lags behind implementation resulting in inconsistencies down the road With expanding threat vectors, IT Security, Information Assurance and Operational Security have become key Ground System architecture drivers New Federal security-related directives are generated on a daily basis, imposing new requirements on current / existing ground systems - These mandated activities and data calls typically carry little or no additional funding for implementation As a result, Ground System Sustaining Engineering groups and Information Technology staff continually struggle to keep up with the rolling tide of security Advancing security concerns and shrinking budgets are pushing these large stove-piped ground systems to begin sharing resources - I.e. Operational / SysAdmin staff, IT security baselines, architecture decisions or even networks / hosting infrastructure Refactoring these existing ground systems into multi-mission assets proves extremely challenging due to what is typically very tight coupling between legacy components As a result, many "Multi-Mission" ops. environments end up simply sharing compute resources and networks due to the difficulty of refactoring into true multi-mission systems Utilizing continuous integration / rapid system deployment technologies in conjunction with an open architecture messaging approach allows System Engineers and Architects to worry less about the low-level details of interfaces between components and configuration of systems GMSEC messaging is inherently designed to support multi-mission requirements, and allows components to aggregate data across multiple homogeneous or heterogeneous satellites or payloads - The highly-successful Goddard Science and Planetary Operations Control Center (SPOCC) utilizes GMSEC as the hub for it's automation and situational awareness capability Shifts focus towards getting GS to a final configuration-managed baseline, as well as multi-mission / big-picture capabilities that help increase situational awareness, promote cross-mission sharing and establish enhanced fleet management capabilities across all levels of the enterprise.

GMSEC↗
NASA NTRS2016

Automated Commanding of the SMAP Spacecraft Enables Efficient, Reliable, and Responsive Operations

The Soil Moisture Active Passive (SMAP) mission developed and deployed a system to autonomously handle most routine commanding of the observatory. This system of ground software is able to build commands, validate them, and radiate the commands to the spacecraft, all without human interaction. In the case of an off -nominal scenario, the system will abort gracefully and notify the mission operations team of the problem. The system was phased into operations during the first three months of the SMAP mission and handles over 90% of the weekly commanding of the vehicle. The gradual introduction of the automation in flight, along with an extensive test campaign, was instrumental in the success of the software. The automation has enabled substantial efficiencies in operations team staffing and has improved reliability by removing the potential for human error. The system also allows the SMAP project to be more responsive which has shown significant benefits in areas of data latency and science accuracy.

automation↗
NASA NTRS2014

Human-Automation Cooperation for Separation Assurance in Future NextGen Environments

A 2012 Human-In-The-Loop air traffic control simulation investigated a gradual paradigm-shift in the allocation of functions between operators and automation. Air traffic controllers staffed five adjacent high-altitude en route sectors, and during the course of a two-week experiment, worked traffic under different function-allocation approaches aligned with four increasingly mature NextGen operational environments. These NextGen time-frames ranged from near current-day operations to nearly fully-automated control, in which the ground systems automation was responsible for detecting conflicts, issuing strategic and tactical resolutions, and alerting the controller to exceptional circumstances. Results indicate that overall performance was best in the most automated NextGen environment. Safe operations were achieved in this environment for twice todays peak airspace capacity, while being rated by the controllers as highly acceptable. However, results show that sector operations were not always safe; separation violations did in fact occur. This paper will describe in detail the simulation conducted, as well discuss important results and their implications.

air traffic control↗
NASA NTRS2016

How Important is Conflict Detection to the Conflict Resolution Task?

To determine the capabilities and limitations of human operators and automation in separation assurance roles, the second of three Human-in-the-Loop (HITL) part-task studies investigates air traffic controllers ability to detect and resolve conflicts under varying task sets, traffic densities, and run lengths. Operations remained within a single sector, staffed by a single controller, and explored, among other things, the controllers conflict resolution performance in conditions with or without their involvement in the conflict detection task. Whereas comparisons of conflict resolution performance between these two conditions are available in a prior publication, this paper explores whether or not other subjective measures display a relationship to that data. Analyses of controller workload and situation awareness measures attempt to quantify their contribution to controllers ability to resolve traffic conflicts.

function allocation↗
NASA NTRS2015

Lessons Learned from Optical Payload for Lasercomm Science (OPALS) Mission Operations

This paper provides an overview of Optical Payload for Lasercomm Science (OPALS) activities and lessons learned during mission operations. Activities described cover the periods of commissioning, prime, and extended mission operations, during which primary and secondary mission objectives were achieved for demonstrating space-to-ground optical communications. Lessons learned cover Mission Operations System topics in areas of: architecture verification and validation, staffing, mission support area, workstations, workstation tools, interfaces with support services, supporting ground stations, team training, procedures, flight software upgrades, post-processing tools, and public outreach.

Sindiy, Oleg V.↗
NASA NTRS2016

Impact of Automation Support on the Conflict Resolution Task in a Human-in-the-Loop Air Traffic Control Simulation

To determine the capabilities and limitations of human operators and automation in separation assurance roles, the second of three Human-in-the-Loop (HITL) part-task studies investigated air traffic controllers ability to detect and resolve conflicts under varying task sets, traffic densities, and run lengths. Operations remained within a single sector, staffed by a single controller, and explored, among other things, the controllers responsibility for conflict resolution with or without their involvement in the conflict detection task. Furthermore, these conditions were examined across two different traffic densities; 1x (current-day traffic) and a 20 increase above current-day traffic levels (1.2x). Analyses herein offer an examination of the conflict resolution strategies employed by controllers. In particular, data in the form of elapsed time between conflict detection and conflict resolution are used to assess if, and how, the controllers involvement in the conflict detection task affected the way in which they resolved traffic conflicts.

human-in-the-loop simulation↗
NASA NTRS2018

Payload Operations Center - Lessons from Commercial Engagement

The International Space Station (ISS) Payload Operations and Integration Center (POIC) at NASA's Marshall Space Flight Center (MSFC) in Huntsville, Alabama, United States, has gone through an evolution from supporting exclusively government ISS users to providing 50% (or more) of their support to commercial users. At the same time, they have expanded ground and facility operations to support a United States Orbital Segment crew expansion from three to four astronauts allowing an additional of 34 hours crew time per week. These additional hours are dedicated to utilization and have already surpassed the 100 hour peak weekly milestone in July 2018. This paper discusses the Center's changes in planning, staffing, coordination, and operations while addressing topics from the addition of secondary flight control positions to dynamic operations product reviews. MSFC's Human Exploration and Development Operations Office, which manages payload operations, seeks through this paper to highlight the higher priority commercial users now receive in replanning and in additional crew time.

Watkins, Bobby J.↗
NASA NTRS2018

Composite Bonded Joint: Repair Development

This report documents the details of my work as a NASA KSC intern for the Fall Session from August 27th to December 14th, 2018. My efforts and contributions were with the Materials Science Branch, a staffed organization within the Laboratories, Development, & Testing (NE-L) Division of the Engineering Directorate. The principle responsibilities of the Materials Science group are to support the design, development, and operations activities for materials and processes with the purpose of providing unique solutions for flight hardware, ground support equipment, and customer requests. My role as an intern focused on assisting engineers in developing repair processes to mature bonded joint technology in support of SLS ? scale hardware. My primary goals for this internship were to become more familiar with composite materials and learn more about processes I was unfamiliar with, such as prepregs and out-of-autoclave processing. This project allowed me to learn new skills such as scarfing and curing composites. Additional goals I had were to learn more about NASA's laboratories and projects under development. This internship not only provided me with those experiences, but also allowed me to build relationships with inspiring engineers; a takeaway I will never forget.

Composite Materials↗
NASA NTRS2014

A Closer Look at Automation Behavior During a Human-in-the-Loop Simulation

A 2012 Human-In-The-Loop air traffic control simulation investigated a gradual paradigm-shift in the allocation of functions between operators and automation. Air traffic controllers staffed five adjacent high-altitude en route sectors, and during the course of a two-week experiment, worked traffic under four different function allocation concepts aligned with increasingly mature NextGen operational environments. These NextGen time-frames ranged from near current-day operations to nearly fully-automated control, in which the ground systems automation was responsible for detecting conflicts, issuing strategic and tactical resolutions, and alerting controllers to exceptional circumstances. This paper continues the investigations reported in previous publications. Analyses of data surrounding the conflict-resolution task serve as the context in which we investigate the interactions between controllers and the automation.

Human-Automation Interaction↗
NASA NTRS2012

Interplanetary CubeSats: Opening the Solar System to a Broad Community at Lower Cost

Interplanetary CubeSats could enable small, low-cost missions beyond low Earth orbit. This class is defined by mass < ~ 10 kg, cost < $30 M, and durations up to 5 years. Over the coming decade, a stretch of each of six distinct technology areas, creating one overarching architecture, could enable comparatively low-cost Solar System exploration missions with capabilities far beyond those demonstrated in small satellites to date. The six technology areas are: (1) CubeSat electronics and subsystems extended to operate in the interplanetary environment, especially radiation and duration of operation; (2) Optical telecommunications to enable very small, low-power uplink/downlink over interplanetary distances; (3) Solar sail propulsion to enable high !V maneuvering using no propellant; (4) Navigation of the Interplanetary Superhighway to enable multiple destinations over reasonable mission durations using achievable !V; (5) Small, highly capable instrumentation enabling acquisition of high-quality scientific and exploration information; and (6) Onboard storage and processing of raw instrument data and navigation information to enable maximum utility of uplink and downlink telecom capacity, and minimal operations staffing. The NASA Innovative Advanced Concepts (NIAC) program in 2011 selected Interplanetary CubeSats for further investigation, some results of which are reported here for Phase 1.

Staehle, Robert L.↗
NASA NTRS2016

Voyager Interstellar Mission: Challenges of Flying a Very Old Spacecraft on a Very Long Mission

Two Voyager spacecraft were launched in 1977. After the successful flybys of Jupiter and Saturn by both Voyagers and Uranus and Neptune by Voyager 2, the mission has been extended for another 30 years in search of the transition region between the dominance of the solar energy and interstellar energy. The Voyager Interstellar Mission (VIM) started on January 1, 1990. It can be characterized by several factors including extremely long communication distances, aging hardware, reduced staffing levels and difficulty in obtaining Deep Space Network (DSN) resources necessitated by the increasing distance between the spacecraft and Earth. The mission was redesigned to compensate for such factors while maximizing the science return. After 25 years of VIM and several significant science discoveries, both Voyager spacecraft are still functioning well and the Voyager flight team is preparing for an even longer mission - until the year 2025 and beyond. In order to work around the challenges and to continue the mission even further, the team has been implementing numerous changes, mainly through flight software modifications and hardware reconfiguration. The major drivers for the changes are two-fold: resource constraints (such as decreasing power output and difficulty in obtaining the necessary DSN coverage) and anomalies due to the aging hardware. The majority of changes occur through flight software modifications so the state of the on-board responses is appropriate for the changing space environment and mission phase, and the flight software is compatible in allowing the maximum data gathering. The on-board flight software routines such as baseline sequence, fault protection routines, the High Gain Antenna POINTing to Earth (HPOINT) table, and long-term events table need to be maintained through flight software updates. The changes also occur through hardware reconfiguration such as selecting the backup Hybrid Buffer Interface Circuits (HYBIC) or attitude propulsion thrusters. This paper will describe the challenges of VIM and what has been done to overcome or mitigate those challenges. The primary focus will be the major flight software changes made during VIM and the changes that are in store for the near future in preparation for continuing the extended mission, from the originally projected year of 2020 out to the year 2025 and possibly beyond.

Matsumoto, Sun Kang↗
NASA NTRS2016

Exploring the Science Trade Space with the JPL Innovation Foundry A-Team

The JPL Innovation Foundry has established a new approach for exploring, developing, and evaluating early concepts with a group called the Architecture Team (A-Team). The A-Team combines innovative collaborative methods and facilitated sessions with subject matter experts and analysis tools to help mature mission concepts. Science, implementation, and programmatic elements are all considered during an ATeam study. In these studies, Concept Maturity Levels (CML) are used to group methods. These levels include idea generation and capture (CML 1), initial feasibility assessment (CML 2), and trade space exploration (CML 3). Methods used for exploring the science objectives, feasibility, and scope will be described including use of a new technique for understanding the most compelling science, called a Science Return Diagram (SRD). In the process of developing the SRD, gradients in the science trade space are uncovered along with their implications for implementation and mission architecture. Special attention is paid towards developing complete investigations, establishing a series of logical claims that lead to the natural selection of a measurement approach. Over 20 science-focused A-Team studies have used these techniques to help science teams refine their mission objectives, make implementation decisions and reveal the mission concept’s most compelling science. This paper will describe the A-Team process for exploring the mission concept's science trade space and the Science Return Diagram technique.In June of 2011 a new collaborative engineering approach forearly concept formulation began in the JPL InnovationFoundry [1], six months later becoming the “A-Team” [2].Responding to a need for exploring mission architecturelevel trades [3], the A-Team precedes Team X [4,5] in asequence of concurrent engineering teams at JPL that can beused to mature a concept from a “cocktail napkin” level ideato a complete mission point design. The A-Team efficientlyexplores the science, implementation, and programmatictrade space in early concept formulation. Small, facilitatedgroups of experts generate innovative ideas, quantitativelyassess feasibility, and discover key sensitivities in the tradespace through collaborative analysis and use of advancedmethods and tools. The A-Team process builds off theexperience within JPL and other recent approaches to earlyconcept formulation [6] including best practices of the JPLInnovation Foundry, Project Systems Engineering &Formulation Section, Team Eureka and the Rapid MissionArchitecture Team[7].The A-Team is a focal point for innovative formulationapproaches and people within JPL. It relies on a largebackground of study resources, creative thinkers and “greybeard” scrutinizers, advanced tools, and subject matterexperts with both breadth and depth in experience andexpertise that are all available at JPL. The A-Team isdesigned to be a rapid and efficient process takingapproximately 6 weeks (the entire process can be as short asjust a few days or as long as up to three months) and costingthe equivalent of a work-month of a full-time employee orless. Studies begin with detailed planning and client reviewfollowed by study sessions, analysis work, and reporting.The staffing on each study is customized to the study goalsand objectives, and it is addressed early in the A-Teamprocess. Sessions are generally half-day or whole-day eventsand conducted over a series of days with focused agendas thatare moderated by a trained facilitator. Preliminary results andknowledge capture are available within hours of each session,and a final report is generally available two weeks later.One of the biggest challenges facing early conceptdevelopment is understanding the gradient in science returnversus various available mission scenarios and payload options. Often times, major areas of scientific inquiry havealready been prioritized by science groups, including throughthe National Research Council’s Decadal Studies inAstronomy, Planetary, and Earth Science. Yet science teamscontinue to struggle, especially in competitive missionsolicitations, to capture the right amount of scope that’sachievable within the cost constraints of the opportunity.Often the desire to completely and comprehensively study ascience area in just one mission (after all, true missionopportunities are rare) drives teams to take on too much,providing requirements that are unachievable within theresources of the opportunity without inducing unacceptableimplementation risk. Alternatively, science teams can seekto reduce risk by using an established instrument, but havenot thought through the traceability and key aspects of thescience question to justify its use. Both scenarios lead to badassumptions at the beginning of the concept development thatcan then ripple through implementation option choices,potentially preventing what would have been a good scienceinvestigation from being selected.The purpose of this paper is first to provide some additionalbackground and summary of the A-Team process, tools,people, and facilities. We then focus on the A-Teammethodology for overcoming the barriers of defining thescience scope well at the early concept development stage.This includes understanding the science story andtraceability, and then examining the gradient in science returnversus key characteristics of observables, developing theright payload and mission requirement specification throughexamining the science and implementation trade space.

Ziemer, John K.↗
NASA NTRS2016

On the Maneuvers Operational Response for NASA’s Soil Moisture Active-Passive (SMAP) Mission

The Soil-Moisture Active-Passive (SMAP) spacecraft requires various kinds of in-orbit maneuvers over the course of its three-year mission. The types of maneuvers include pre-planned commissioning maneuvers to reach its science orbit, regularly executed orbit maintenance maneuvers to overcome drag and other nominally occurring phenomena, as well as (the possibility of) collision avoidance maneuvers. The architecture of the spacecraft – in terms of availability of commanding via ground assets, the inherited avionics' ability to sequence and execute commands, and the capability of available subsystems able to carry out maneuvers – was well defined early in the development of the spacecraft and mission, well before the operational plan for responding to maneuver requests was cemented. The systems engineering challenge became: how to accommodate all three types of maneuvers in the confines of this well-defined architecture. This paper will describe how the operations team on SMAP successfully met this challenge. Specifically, it will dive into the three pronged approach that SMAP developed to handle each type of maneuver described above – to meet the timeliness requirements leveraged on the operations team to execute said maneuvers, while continuing to fit within the allotted staffing profile during nominal operations. Defining this paradigm to fit the mission’s architecture meant re-defining the original paradigm, (planned maneuvers being thought of separately than collision avoidance maneuvers), and re-classifying all responses to maneuver requests as variations and permutations of a singular operational response to a maneuver request. This paper will also describe the tools that were created to simplify the human interface and automate as much of the response as was possible. Finally, this paper will describe, at a very high level, some of the problems encountered and lessons learned by the operations team when this process was executed the first four times during the first ninety days of operations. Though the architecture of the operations team's response to maneuver requests will never be repeated exactly, the flexibility that was inserted via redefining the scope of the problem and by redefining the human interfaces should influence future projects' architectures earlier in their development – in the hopes that said influence will save time and money in the future.

Tirona, Joseph↗
NASA NTRS2020

History and Logic Model NASA Goddard Space Flight Center Instrument and Payload Systems Engineering Technical Performance Study

Historically, some NASA missions have exceeded schedule and cost commitments. Studies suggest technical performance is a contributor. The 1980 NASA Project Management Study concluded, "one of the most significant contributors to cost and schedule growth is inadequate definition of technical and management aspects of a program..." (as cited in GAO/NSIAD-93-97, p. 11). The 1991 NASA Roles and Missions Report identified a "need for increased emphasis on technological readiness and requirements on the front end of a program" (as cited in GAO/NSIAD-93-97, p. 11). The 1992 NASA Program Costs Report stated that NASA officials identified, among other things, "insufficient definition studies... [and] program redesigns and technical complexities" as reasons for cost and schedule overruns (GAO/NSAID-93-97, p. 11). The 2002 Task Force on Acquisition of National Security Space Programs found "requirements definition and control issues, unhealthy cost bias in proposal evaluation, widespread lack of budget reserves required to implement high risk programs on schedule, and an overall underappreciation of the importance of appropriately staffed and trained system engineering staff to manage the technologically demanding and unique aspects of space programs" (DoD, 2003, p.i.) In 2007, The NASA Office of the Chief Engineer chartered the NASA Instrument Capability Study (NICS) “to determine whether NASA instrument developers are facing challenges that impact the capability to design and build quality instruments or whether there are flaws in the acquisition strategy evidenced by schedule delays, cost overruns, and increased technical risk via design deficiencies. The... team was also chartered to determine if occurrences [are]... isolated cases or if there are generic issues... If the issues [are] found to be generic, the team [is] to offer solutions to recover such capability" (NICS Report, 2008, p. vi). The 2008 NICS Report, led by Goddard Space Flight Center (GSFC), identified challenges to instrument technical performance consistent with findings from previous reports. In 2017, the Instrument Project Division (IPD) Implementation Study was initiated to determine if there was a change in meeting schedule and cost commitments after implementing certain NICS recommendations. In 2018, the Instrument Technical Performance Study was initiated to determine the current state of Instrument Technical Performance in the GSFC Payload & Instrument Systems Engineering Branch. The purpose of the combined studies is to answer the question, "Is there a relationship between meeting NASA scientific instrument technical success and meeting schedule and cost commitments? If yes, what is the relationship?" References Department of Defense Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics. (2003). The report of the defense science board/ air force scientific advisory board joint task force on acquisition of national security space programs. Washington DC. Government Accounting Office. (1992). NASA program costs: Space missions require substantially more funding than initially estimated. GAO/NSIAD-93-97. Washington DC. National Aeronautics and Space Administration, National Oceanic and Atmospheric Agency, Department of Defense. (2008). The NASA instrument capability study final report. NP-2008-11-058-GSFC. Washington DC.

Robbins, Geraldine↗
NASA NTRS2020

Remote Support of ISS Payload Operations During the COVID19 Pandemic

As part of the Human Health and Performance Contract (HHPC) with the NASA Johnson Space Center, the Human Research Program’s (HRP) Research Operations and Integration (ROI) element conducts the planning, implementation, and closing of human research operations on-board the International Space Station (ISS). These operations are supported out of the Telescience Support Center (TSC) located in the Mission Control Center at Houston’s Johnson Space Center (MCC-H). HRP ROI has an Emergency Response Plan in place to allow for remote operations to be completed in the case of inclement weather or other natural disaster; however, nominally, the remote support is only expected to last one to two weeks. In response to the COVID-19 global pandemic, HRP ROI was challenged to complete a quick transition to supporting on-orbit operations remotely and distanced for an indefinite amount of time. This shift in ground support required close collaboration with various external groups as well as the implementation or adaptation of various technologies and tools to ensure no loss of science data. Operational adjustments were put into place for ground commanding, telemetry monitoring, personnel staffing and private and public audio and video with the ISS. Adjustments were also put in place for communication and collaboration with MCC-H, the Payload Operation and Integration Center (POIC) at Marshall Space Flight Center (MSFC), as well as between the various HRP ROI console team members spread across Houston, TX. The ability to successfully support a variety of on-orbit operations from any remote location is more in demand as the commercialization of low Earth orbit is expanding.

Operations↗
NASA NTRS1994

Increases in Efficiency and Enhancements to the Mars Observer Non-stored Commanding Process

The Mars Observer team was, until the untimely loss of the spacecraft on August 21, 1993, performing flight operations with greater efficiency and speed than any previous JPL mission of its size. This level of through-put was made possible by a Mission Operations System which was composed of skilled personnel using sophisticated sequencing and commanding tools. During cruise flight operations, however, it was realized by the project that this commanding level was not going to be sufficient to support the activities planned for the mapping operations. The project had committed to providing the science instrument principle investigators with a much higher level of commanding during mapping. Thus, the project began taking steps to enhance the capabilities of the flight team. One mechanism used by project management was a tool available from Total Quality Management (TQM). This tool is known as a Process Action Team (PAT). The Mars Observer PAT was tasked to increase the capacity of the flight team's non-stored commanding process by fifty percent with no increase in staffing and a minimal increase in risk. The outcome of this effort was to, in fact, increase the capacity by a factor of 2.5 rather than the desired fifty percent and actually reduce risk. The majority of these improvements came from the automation of the existing command process. The results required very few changes to the existing mission operations system. Rather, the PAT was able to take advantage of automation capabilities inherent in the existing system and make changes to the existing flight team procedures. This paper will describe in detail the enhancements recommended by the PAT for the non-stored command generation process on Mars Observer. This will be contrasted with the process used by the flight team prior to implementation of these improvements. Finally, there will be a discussion of the applicability of the techniques devised by the PAT for enhancement of the non-stored command process to present and future projects.

Process↗
NASA NTRS2019

Requirements Development and Management on the Psyche Project

In January 2017, Psyche was one of two mission concepts selected by NASA for flight as part of the 14th Discovery mission competition. The project has been staffing up and maturing the spacecraft, instrument and mission system baseline designs on the path towards a 2022 launch. During much of 2018, the Project has been executing the lifecycle stage called Phase B, “Preliminary Design and Technology Completion,” one key element of which is the development and management of requirements at various levels. In the case of the Psyche project, this process has been particularly unique for several reasons. The project utilizes a Solar Electric Propulsion (SEP) Chassis from Space Systems Loral (SSL), a high volume manufacturer of commercial geostationary (GEO) telecom spacecraft based on the 1300 satellite bus. While SSL has an extensive, well-vetted set of requirements based on their very successful Earth-orbiting product line, translating that heritage to a deep space science mission required special care. In addition to the differences associated with the deep space environment and longer communication times, new interfaces had to be incorporated. While a substantial portion of the Flight System consists of the SEP Chassis, there were several new interfaces within various subsystems between SSL components and those provided by JPL and other contractors. Managing these interfaces through requirements at a relatively higher level than normally seen on internal or external builds proved challenging. Finally, the Psyche spacecraft plans to host the flight terminal of the Deep Space Optical Communications (DSOC) technology demonstration, which is itself a separate project with its own requirements that must be flowed down and managed. This paper will present an overview of the requirement development and management process for the Psyche project. It will discuss in detail the various challenges summarized above, the methods and decisions chosen to address them, and evaluate their overall effectiveness at this stage in the project.

Elkins-Tanton, Linda T.↗