Search NASASearch

SEARCH · Search NASA

Results for “Process Mission Teams”

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

Reinventing The Design Process: Teams and Models

The future of space mission designing will be dramatically different from the past. Formerly, performance-driven paradigms emphasized data return with cost and schedule being secondary issues. Now and in the future, costs are capped and schedules fixed-these two variables must be treated as independent in the design process. Accordingly, JPL has redesigned its design process. At the conceptual level, design times have been reduced by properly defining the required design depth, improving the linkages between tools, and managing team dynamics. In implementation-phase design, system requirements will be held in crosscutting models, linked to subsystem design tools through a central database that captures the design and supplies needed configuration management and control. Mission goals will then be captured in timelining software that drives the models, testing their capability to execute the goals. Metrics are used to measure and control both processes and to ensure that design parameters converge through the design process within schedule constraints. This methodology manages margins controlled by acceptable risk levels. Thus, teams can evolve risk tolerance (and cost) as they would any engineering parameter. This new approach allows more design freedom for a longer time, which tends to encourage revolutionary and unexpected improvements in design.

Wall, Stephen D.

Relevant Parameter Evolution in Team X Mission Concept Designs

The Advanced Projects Design Team, also known as Team X, is a concurrent engineering team that quickly and cheaply designs space mission architectures including the flight system and subsystems, the trajectory, and ground system. Through the use of ICEMaker, an Excel spreadsheet database, the parameters from each subsystem can be shared and used among the other subsystems. This allows for entire missions to be planned with only a few short design team sessions. Based on the results, the feasibility of the mission concept can be determined. Over the Years since the team was created, the amount of information being shared among subsystems on the database has increased, however many of the parameters are now obsolete. Removal of these unused parameters Will clean UP the database and help to streamline the mission design process. By comparing parameter files from previous Team X mission studies, the parameter usage can be determined. As was initially suspected there are more unused parameters on the database than parameters that are actually used.

Huelman, Brandon N.

Using Modern Methodologies with Maintenance Software

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.

Scrum

Enterprise Mission Integration for Artemis Lunar Missions

Mission integration is an iterative process by which a specific mission is formulated, refined, planned, and executed within the established vehicle(s), architecture, and ground systems design. Mission integration includes the people, vehicle(s) and ground hardware/software, products, processes, analyses, schedules, facilities, Certification of Flight Readiness, etc. The Artemis Mission Integration Task Team (MITT) developed a series of products and processes to support the complex mission integration across various Programs within the Artemis Mission Campaign (Orion, Space Launch Systems, Exploration Ground Systems, Gateway, Human Landing System, and Extravehicular Activity and Human Surface Mobility). The Moon to Mars (M2M) Program is referred to as ‘the enterprise’ as it includes both the M2M organization and the Programs supporting the Artemis Mission Campaign. Artemis Mission Integration has five phases: mission capability, mission definition, mission preparation, mission execution, and post-mission assessment. This paper focuses on one of the enterprise-level mission checkpoints as a kick-off to the Mission Preparation phase, the Mission Integration Review (MIR), which occurs 18-24 months prior to launch. The MIR helps to confirm the defined mission technical baseline is within the existing analyzed design envelope. Details are provided on the identification of dependencies, issues, or gaps for mission-specific objectives and requirements, as well as the definition of the analysis, training, mission execution products, facilities, and detailed supporting operations requirements. The MIR was held for both Artemis I and II and this paper aims to share with the aerospace community its value as we prepare for upcoming Artemis Missions.

Mary Anne Plaza

Proven and Robust Ground Support Systems - GSFC Success and Lessons Learned

Over the past fifteen years, Goddard Space Flight Center has developed several successful science missions in-house: the Wilkinson Microwave Anisotropy Probe (WMAP), the Imager for Magnetopause-to-Aurora Global Exploration (IMAGE), the Earth Observing 1 (EO-1) [1], and the Space Technology 5 (ST-5)[2] missions, several Small Explorers, and several balloon missions. Currently in development are the Solar Dynamics Observatory (SDO) [3] and the Lunar Reconnaissance Orbiter (LRO)[4]. What is not well known is that these missions have been supported during spacecraft and/or instrument integration and test, flight software development, and mission operations by two in house satellite Telemetry and Command (T & C) Systems, the Integrated Test and Operations System (ITOS) and the Advanced Spacecraft Integration and System Test (ASIST). The advantages of an in-house satellite Telemetry and Command system are primarily in the flexibility of management and maintenance - the developers are considered a part of the mission team, get involved early in the development process of the spacecraft and mission operations-control center, and provide on-site, on-call support that goes beyond Help Desk and simple software fixes. On the other hand, care must be taken to ensure that the system remains generic enough for cost effective re-use from one mission to the next. The software is designed such that many features are user-configurable. Where user-configurable options were impractical, features were designed so as to be easy for the development team to modify. Adding support for a new ground message header, for example, is a one-day effort because of the software framework on which that code rests. This paper will discuss the many features of the Goddard satellite Telemetry and Command systems that have contributed to the success of the missions listed above. These features include flexible user interfaces, distributed parallel commanding and telemetry decommutation, a procedure language, the interfaces and tools needed for a high degree of automation, and instantly accessible archives of spacecraft telemetry. It will discuss some of the problems overcome during development, including secure commanding over networks or the Internet, constellation support for the three satellites that comprise the ST-5 mission, and geographically distributed telemetry end users.

Pfarr, Barbara

Managing Risk for Cassini During Mission Operations and Data Analysis (MOandDA)

A Risk Management Process has been tailored for Cassini that not only satisfies the requirements of NASA and JPL, but also allows the Program to proactively identify and assess risks that threaten mission objectives. Cassini Risk Management is a team effort that involves both management and engineering staff. The process is managed and facilitated by the Mission Assurance Manager (MAM), but requires regular interactions with Program Staff and team members to instill the risk management philosophy into the day to day mission operations. While Risk Management is well defined for projects in the development phase, it is a relatively new concept for Mission Operations. The Cassini team has embraced this process and has begun using it in an effective, proactive manner, to ensure mission success. It is hoped that the Cassini Risk Management Process will form the basis by which risk management is conducted during MO&DA on future projects. proactive in identifying, assessing and mitigating risks before they become problems. Cost ehtiveness is achieved by: Comprehensively identifying risks Rapidly assessing which risks require the expenditure of pruject cewums Taking early actions to mitigate these risks Iterating the process frequently, to be responsive to the dynamic internal and external environments The Cassini Program has successfully implemented a Risk Management Process for mission operations, The initial SRL has been developed and input into he online tool. The Risk Management webbased system has been rolled out for use by the flight team and risk owners we working proactive in identifying, assessing and mitigating risks before they become problems. Cost ehtiveness is achieved by: Comprehensively identifying risks Rapidly assessing which risks require the expenditure of pruject cewums Taking early actions to mitigate these risks Iterating the process frequently, to be responsive to the dynamic internal and external environments The Cassini Program has successfully implemented a Risk Management Process for mission operations, The initial SRL has been developed and input into he online tool. The Risk Management webbased system has been rolled out for use by the flight team and risk owners we working put into place will become visible and will be illusmted in future papers.

risk management

Architecture in Mission Integration, Choreographing Constraints

In any building project the Architect's role and skill is to balance the client's requirements with the available technology, a site and budget. Time, place and resources set the boundaries and constraints of the project. If these boundaries are correctly understood and respected by the Architect they can be choreographed into producing a facility that abides by those constraints and successfully meets the clients needs. The design and assembly of large scale space facilities whether in orbit around or on the surface of a planet require and employs these same skills. In this case the site is the International Space Station (ISS) which operates at a nominal rendezvous altitude of 220 nautical miles. With supplies to support a 7 day mission the Shuttle nominally has a cargo capacity of 35,000 pounds to that altitude. Through the Mission Integration process the Launch Package Management Team choreographs the constraints of ascent performance, hardware design, cargo, rendezvous, mission duration and assembly time in order to meet the mission objective.

Jones, Rod

Tracking the Short Term Planning (STP) Development Process

Part of the National Aeronautics and Space Administration?s mission is to pioneer the future in space exploration, scientific discovery and aeronautics research is enhanced by discovering new scientific tools to improve life on earth. Sequentially, to successfully explore the unknown, there has to be a planning process that organizes certain events in the right priority. Therefore, the planning support team has to continually improve their processes so the ISS Mission Operations can operate smoothly and effectively. The planning support team consists of people in the Long Range Planning area that develop timelines that includes International Partner?s Preliminary STP inputs all the way through to publishing of the Final STP. Planning is a crucial part of the NASA community when it comes to planning the astronaut?s daily schedule in great detail. The STP Process is in need of improvement, because of the various tasks that are required to be broken down in order to get the overall objective of developing a Final STP done correctly. Then a new project came along in order to store various data in a more efficient database. "The SharePoint site is a Web site that provides a central storage and collaboration space for documents, information, and ideas."

Price, Melanie

Automated Data Accountability for Missions in Mars Rover Data

As the Mars Curiosity Rover transmits data to the JPL Ground Data System (GDS), it frequently observes data loss and corruption, requiring re-transmits from the rover and Ground Data System Analysts (GDSA) to monitor the downlink process. As new missions are launched, the GDSA team redistributes analysts to these new missions, causing shortages in previous missions. The GDSA team can significantly benefit from the automation and optimization of the downlink process of telemetry data. In fact, there is a need for a better understanding of why the data is corrupted, so that the GDSA team can best determine the root cause of the issues in the GDS. This paper presents machine learning and deep learning based approaches to automate and optimize the detection of data loss. We first created a pipeline to automatically accumulate data from the telemetry databases (MAROS, Telemetry Data Storage, and GDS Elastic Search Database) in the downlink process. With our newly created datasets, we perform feature selection to supplement the GDSA understanding of the downlink process and provide supplemental analysis on the importance of different features. We implement various machine learning and deep learning based models, including support vector machines, ensemble methods, and deep neural networks and evaluate their accuracies in identifying whether a downlink process is complete or incomplete. We utilize fast hyperparameter optimization methods that allow our models to quickly be re-trained, allowing them to quickly be tuned and optimized on daily incoming data in real time. This hyperparameter optimization also allows our methods to be quickly integrated into other JPL missions. Our results show that our best-performing machine learning and deep learning based models outperform the existing GDSA detection software by 6 accuracy points and can aid analysts by providing insights into the data accountability problem. Since these various machine learning and deep learning approaches vary significantly in interpretability, we provide a discussion on the tradeoffs between their performance and trustworthiness in helping detect issues in data transmission.

Divsalar, Dariush

OPALS: Mission System Operations Architecture for an Optical Communications Demonstration on the ISS

In spring 2014, the Optical PAyload for Lasercomm Science (OPALS) will launch to the International Space Station (ISS) to demonstrate space-to-ground optical communications. During a 90-day baseline mission, OPALS will downlink high quality, short duration videos to the Optical Communications Telescope Laboratory (OCTL) in Wrightwood, California. To achieve mission success, interfaces to the ISS payload operations infrastructure are established. For OPALS, the interfaces facilitate activity planning, hazardous laser operations, commanding, and telemetry transmission. In addition, internal processes such as pointing prediction and data processing satisfy the technical requirements of the mission. The OPALS operations team participates in Operational Readiness Tests (ORTs) with external partners to exercise coordination processes and train for the overall mission. The tests have provided valuable insight into operational considerations on the ISS.

Abrahamson, Matthew J.

Opals: Mission System Operations Architecture for an Optical Communications Demonstration on the ISS

In April of 2014, the Optical PAyload for Lasercomm Science (OPALS) Flight System (FS) launched to the International Space Station (ISS) to demonstrate space-to-ground optical communications. During a planned 90-day baseline mission, the OPALS FS will downlink high quality, short duration videos to the Optical Communications Telescope Laboratory (OCTL) ground station in Wrightwood, California. Interfaces to the ISS payload operations infrastructure have been established to facilitate activity planning, hazardous laser operations, commanding, and telemetry transmission. In addition, internal processes, such as pointing prediction and data processing, satisfy the technical requirements of the mission. The OPALS operations team participates in Operational Readiness Tests (ORTs) with external partners to exercise coordination processes and train for the overall mission. The ORTs have provided valuable insight into operational considerations for the instrument on the ISS.

Technology Demonstration

Mission Operations and Command Assurance: Flight Operations Quality Improvements

Mission Operations and Command Assurance (MO&CA) is a Total Quality Management (TQM) task on JPL projects to instill quality in flight mission operations. From a system engineering view, MO&CA facilitates communication and problem-solving among flight teams and provides continuous process improvement to reduce risk in mission operations by addressing human factors. The MO&CA task has evolved from participating as a member of the spacecraft team to an independent team reporting directly to project management and providing system level assurance. JPL flight projects have benefited significantly from MO&CA's effort to contain risk and prevent rather than rework errors. MO&CA's ability to provide direct transfer of knowledge allows new projects to benefit from previous and ongoing flight experience.

mission

Space station control center architecture

The Space Station control center (SSCC) is under the cognizance of the Johnson Space Center and is located adjacent to the Shuttle's mission control center. Responsibility for design, development, and operations of the control center is the responsibility of the mission operations directorate at JSC. Space Station Ground Systems Division is responsible for design and development of the control center systems which is currently in process under the mission support contractor team led by Loral Space Information Systems. It is early in the life cycle of the SSCC project. System functional design review was completed. Subsystem requirements are now being developed and reviewed. A new facility will be available for development activities.

Schmalz, Karen

Mission operations and command assurance: Flight operations quality improvements

Mission Operations and Command Assurance (MO&CA) is a Total Quality Management (TQM) task on JPL projects to instill quality in flight mission operations. From a system engineering view, MO&CA facilitates communication and problem-solving among flight teams and provides continuous solving among flight teams and provides continuous process improvement to reduce risk in mission operations by addressing human factors. The MO&CA task has evolved from participating as a member of the spacecraft team, to an independent team reporting directly to flight project management and providing system level assurance. JPL flight projects have benefited significantly from MO&CA's effort to contain risk and prevent rather than rework errors. MO&CA's ability to provide direct transfer of knowledge allows new projects to benefit from previous and ongoing flight experience.

Welz, Linda L.

Project Report: Automatic Sequence Processor Software Analysis

The Mission Planning and Sequencing (MPS) element of Multi-Mission Ground System and Services (MGSS) provides space missions with multi-purpose software to plan spacecraft activities, sequence spacecraft commands, and then integrate these products and execute them on spacecraft. Jet Propulsion Laboratory (JPL) is currently is flying many missions. The processes for building, integrating, and testing the multi-mission uplink software need to be improved to meet the needs of the missions and the operations teams that command the spacecraft. The Multi-Mission Sequencing Team is responsible for collecting and processing the observations, experiments and engineering activities that are to be performed on a selected spacecraft. The collection of these activities is called a sequence and ultimately a sequence becomes a sequence of spacecraft commands. The operations teams check the sequence to make sure that no constraints are violated. The workflow process involves sending a program start command, which activates the Automatic Sequence Processor (ASP). The ASP is currently a file-based system that is comprised of scripts written in perl, c-shell and awk. Once this start process is complete, the system checks for errors and aborts if there are any; otherwise the system converts the commands to binary, and then sends the resultant information to be radiated to the spacecraft.

sequencing

Workflow-Based Software Development Environment

The Software Developer's Assistant (SDA) helps software teams more efficiently and accurately conduct or execute software processes associated with NASA mission-critical software. SDA is a process enactment platform that guides software teams through project-specific standards, processes, and procedures. Software projects are decomposed into all of their required process steps or tasks, and each task is assigned to project personnel. SDA orchestrates the performance of work required to complete all process tasks in the correct sequence. The software then notifies team members when they may begin work on their assigned tasks and provides the tools, instructions, reference materials, and supportive artifacts that allow users to compliantly perform the work. A combination of technology components captures and enacts any software process use to support the software lifecycle. It creates an adaptive workflow environment that can be modified as needed. SDA achieves software process automation through a Business Process Management (BPM) approach to managing the software lifecycle for mission-critical projects. It contains five main parts: TieFlow (workflow engine), Business Rules (rules to alter process flow), Common Repository (storage for project artifacts, versions, history, schedules, etc.), SOA (interface to allow internal, GFE, or COTS tools integration), and the Web Portal Interface (collaborative web environment

Izygon, Michel E.

Research on Intelligent Synthesis Environment

The ultimate goal of this research project is to develop a methodology for the assessment and continuous improvement of engineering team effectiveness in distributed collaborative environments. This review provides the theoretical foundation upon which subsequent empirical work will be based. Our review of the team performance literature has identified the following 12 conceptually distinct team interaction processes as characteristic of effective teams. 1) Mission Analysis; 2) Resource Distribution; 3) Leadership; 4) Timing; 5) Intra-team Feedback; 6) Motivational Functions; 7) Team Orientation; 8) Communication; 9) Coordination; 10) Mutual Performance Monitoring; 11) Back-up Behaviors; and 12) Cooperation. In addition, this review summarizes how team task characteristics (i.e., task type, task complexity, motivation, and temporal changes), team characteristics (i.e., team structure and team knowledge), and individual team member characteristics (i.e., dispositions and teamwork knowledge, skills, and abilities) affect team interaction processes, determine the relevance of these processes, and influence team performance. The costs and benefits of distributed team collaboration are also considered. The review concludes with a brief discussion of the nature of collaborative team engineering tasks.

Loftin, R. Bowen