SEARCH · Engineering Papers

Results for “Commanding”

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.

SourceResearch connectionFrom yearThrough year

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

At least 865 records · Page 48

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide single button intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system on-board the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System [1] , along with the execution component design from within the HAL 9000 Space Operating System [2] , this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA s Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie↗

NASA NTRS2012

Automated Operations Development for Advanced Exploration Systems

Automated space operations command and control software development and its implementation must be an integral part of the vehicle design effort. The software design must encompass autonomous fault detection, isolation, recovery capabilities and also provide "single button" intelligent functions for the crew. Development, operations and safety approval experience with the Timeliner system onboard the International Space Station (ISS), which provided autonomous monitoring with response and single command functionality of payload systems, can be built upon for future automated operations as the ISS Payload effort was the first and only autonomous command and control system to be in continuous execution (6 years), 24 hours a day, 7 days a week within a crewed spacecraft environment. Utilizing proven capabilities from the ISS Higher Active Logic (HAL) System, along with the execution component design from within the HAL 9000 Space Operating System, this design paper will detail the initial HAL System software architecture and interfaces as applied to NASA's Habitat Demonstration Unit (HDU) in support of the Advanced Exploration Systems, Autonomous Mission Operations project. The development and implementation of integrated simulators within this development effort will also be detailed and is the first step in verifying the HAL 9000 Integrated Test-Bed Component [2] designs effectiveness. This design paper will conclude with a summary of the current development status and future development goals as it pertains to automated command and control for the HDU.

Haddock, Angie T.↗

NASA NTRS2013

Orion MPCV GN and C End-to-End Phasing Tests

End-to-end integration tests are critical risk reduction efforts for any complex vehicle. Phasing tests are an end-to-end integrated test that validates system directional phasing (polarity) from sensor measurement through software algorithms to end effector response. Phasing tests are typically performed on a fully integrated and assembled flight vehicle where sensors are stimulated by moving the vehicle and the effectors are observed for proper polarity. Orion Multi-Purpose Crew Vehicle (MPCV) Pad Abort 1 (PA-1) Phasing Test was conducted from inertial measurement to Launch Abort System (LAS). Orion Exploration Flight Test 1 (EFT-1) has two end-to-end phasing tests planned. The first test from inertial measurement to Crew Module (CM) reaction control system thrusters uses navigation and flight control system software algorithms to process commands. The second test from inertial measurement to CM S-Band Phased Array Antenna (PAA) uses navigation and communication system software algorithms to process commands. Future Orion flights include Ascent Abort Flight Test 2 (AA-2) and Exploration Mission 1 (EM-1). These flights will include additional or updated sensors, software algorithms and effectors. This paper will explore the implementation of end-to-end phasing tests on a flight vehicle which has many constraints, trade-offs and compromises. Orion PA-1 Phasing Test was conducted at White Sands Missile Range (WSMR) from March 4-6, 2010. This test decreased the risk of mission failure by demonstrating proper flight control system polarity. Demonstration was achieved by stimulating the primary navigation sensor, processing sensor data to commands and viewing propulsion response. PA-1 primary navigation sensor was a Space Integrated Inertial Navigation System (INS) and Global Positioning System (GPS) (SIGI) which has onboard processing, INS (3 accelerometers and 3 rate gyros) and no GPS receiver. SIGI data was processed by GN&C software into thrust magnitude and direction commands. The processing changes through three phases of powered flight: pitchover, downrange and reorientation. The primary inputs to GN&C are attitude position, attitude rates, angle of attack (AOA) and angle of sideslip (AOS). Pitch and yaw attitude and attitude rate responses were verified by using a flight spare SIGI mounted to a 2-axis rate table. AOA and AOS responses were verified by using a data recorded from SIGI movements on a robotic arm located at NASA Johnson Space Center. The data was consolidated and used in an open-loop data input to the SIGI. Propulsion was the Launch Abort System (LAS) Attitude Control Motor (ACM) which consisted of a solid motor with 8 nozzles. Each nozzle has active thrust control by varying throat area with a pintle. LAS ACM pintles are observable through optically transparent nozzle covers. SIGI movements on robot arm, SIGI rate table movements and LAS ACM pintle responses were video recorded as test artifacts for analysis and evaluation. The PA-1 Phasing Test design was determined based on test performance requirements, operational restrictions and EGSE capabilities. This development progressed during different stages. For convenience these development stages are initial, working group, tiger team, Engineering Review Team (ERT) and final.

Neumann, Brian C.↗

NASA NTRS2013

Sample Analysis at Mars Instrument Simulator

The Sample Analysis at Mars Instrument Simulator (SAMSIM) is a numerical model dedicated to plan and validate operations of the Sample Analysis at Mars (SAM) instrument on the surface of Mars. The SAM instrument suite, currently operating on the Mars Science Laboratory (MSL), is an analytical laboratory designed to investigate the chemical and isotopic composition of the atmosphere and volatiles extracted from solid samples. SAMSIM was developed using Matlab and Simulink libraries of MathWorks Inc. to provide MSL mission planners with accurate predictions of the instrument electrical, thermal, mechanical, and fluid responses to scripted commands. This tool is a first example of a multi-purpose, full-scale numerical modeling of a flight instrument with the purpose of supplementing or even eliminating entirely the need for a hardware engineer model during instrument development and operation. SAMSIM simulates the complex interactions that occur between the instrument Command and Data Handling unit (C&DH) and all subsystems during the execution of experiment sequences. A typical SAM experiment takes many hours to complete and involves hundreds of components. During the simulation, the electrical, mechanical, thermal, and gas dynamics states of each hardware component are accurately modeled and propagated within the simulation environment at faster than real time. This allows the simulation, in just a few minutes, of experiment sequences that takes many hours to execute on the real instrument. The SAMSIM model is divided into five distinct but interacting modules: software, mechanical, thermal, gas flow, and electrical modules. The software module simulates the instrument C&DH by executing a customized version of the instrument flight software in a Matlab environment. The inputs and outputs to this synthetic C&DH are mapped to virtual sensors and command lines that mimic in their structure and connectivity the layout of the instrument harnesses. This module executes, and thus validates, complex command scripts prior to their up-linking to the SAM instrument. As an output, this module generates synthetic data and message logs at a rate that is similar to the actual instrument.

Benna, Mehdi↗

NASA NTRS2012

Irreducible Tests for Space Mission Sequencing Software

As missions extend further into space, the modeling and simulation of their every action and instruction becomes critical. The greater the distance between Earth and the spacecraft, the smaller the window for communication becomes. Therefore, through modeling and simulating the planned operations, the most efficient sequence of commands can be sent to the spacecraft. The Space Mission Sequencing Software is being developed as the next generation of sequencing software to ensure the most efficient communication to interplanetary and deep space mission spacecraft. Aside from efficiency, the software also checks to make sure that communication during a specified time is even possible, meaning that there is not a planet or moon preventing reception of a signal from Earth or that two opposing commands are being given simultaneously. In this way, the software not only models the proposed instructions to the spacecraft, but also validates the commands as well.To ensure that all spacecraft communications are sequenced properly, a timeline is used to structure the data. The created timelines are immutable and once data is as-signed to a timeline, it shall never be deleted nor renamed. This is to prevent the need for storing and filing the timelines for use by other programs. Several types of timelines can be created to accommodate different types of communications (activities, measurements, commands, states, events). Each of these timeline types requires specific parameters and all have options for additional parameters if needed. With so many combinations of parameters available, the robustness and stability of the software is a necessity. Therefore a baseline must be established to ensure the full functionality of the software and it is here where the irreducible tests come into use.

sequencing test↗

NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗

NASA NTRS2019

Effectiveness of Redundant Communications Systems in Maintaining Operational Control of Small Unmanned Aircraft

NASA has been researching prototype technologies for an Unmanned Aircraft System (UAS) Traffic Management (UTM) system to facilitate enabling of safe and efficient civilian low-altitude airspace and UAS operations, in a series of Technical Capability Levels (TCL) activities that are increasingly complex. In TCL1, completed in 2015, visual line-of-sight operations such as agriculture, firefighting and infrastructure monitoring were addressed with a focus on geofencing and operations scheduling. Technologies and requirements needed for beyond visual line-of-sight (BVLOS) operations in sparsely populated areas were examined in TCL2 in 2016, and those for operations over moderately populated areas in TCL3 in 2017 and 2018. TCL4 will build on the earlier TCLs and focus on technologies and requirements for operations in higher-density urban areas for tasks such as news gathering, package delivery and for managing large-scale contingencies. This paper describes a communications test conducted in TCL3 and discusses insights gained from the test. In the test, operators were directed to equip UAS with redundant Command and Control (C2) communications systems, send a maneuver command to Unmanned Aircraft (UA) via the primary system, then verify execution of the sent command. This exercise was repeated with each redundant system. The test was designed to assess effectiveness of redundant C2 systems in maintaining operational control of UA. Several UAS were configured with varying arrangements to achieve redundancy, including two identical radio modems using the same frequency band, WiFi and Long-Term Evolution (LTE) cellular modems, etc. From the test, digital data such as time maneuver command sent, time maneuver verified, etc., were collected. Descriptions of methods to detect loss of C2 communications and contingency steps for such event were collected and assessed. The final paper will include a detailed analysis of the collected data leading to the following insights. First, effectiveness of redundant C2 systems depends on several factors, such as operational environment and communications service availability. For example, use of two identical point-to-point radio to connect operator and UA on the same frequency band can be effective in mitigating radio malfunction when operating in an environment where possibility of Radio Frequency (RF) interference is low, such as over open plains. However, the same arrangement may not be effective where high level of RF transmissions in broad spectrum ranges can be expected, such as over or near urban areas. For redundant systems that consist of external communications services, such as cellular and satellite communications network, redundancy is maintained only in the areas where more than one services are available. Therefore, UAS operators should have the means to plan for and monitor the performance of external communications services they are relying on to control UA. Second, communications performance needs, such as the minimum data transfer rate and the maximum tolerable latency, should be assessed to reflect the potential hazard that can come from loss of UA control. For example, UA operations over desolate area pose less hazard to people than operations over densely populated area and performance need for the former would be less than the latter.

Jung, Jaewoo↗

NASA NTRS2020

U.S. Coast Guard Boat Recovery Simulation at the NASA Ames Vertical Motion Simulator

The U.S. Coast Guard routinely uses the Over-The-Horizon (OTH-IV), a cutter deployed, rigid-hulled inflatable boat for rescue and law enforcement operations. The term "cutter" refers to a Coast Guard vessel 65 feet in length or greater with accommodations for crew to live aboard and the ability to deploy smaller boats including the OTH-IV. A deployment method employed by some cutter class vessels is a davit crane system and specialized hook mechanism to connect the smaller boat. The launch and recovery operation requires several crewmembers, where one is tasked with releasing and connecting the hook to the small boat. Manipulating the hook can pose a risk to the crewmember depending on sea conditions combined with fatigue level or task expertise. Equipment and crewmembers are tested extensively due to the inherent risk of the task, but the sea conditions cannot be controlled. To address the sea condition variable, the U.S. Coast Guard and NASA leveraged the Vertical Motion Simulator (VMS) as a platform to test new equipment or train crewmembers in varying sea conditions. With 6 degrees of freedom and a vertical displacement of +/- 22ft, the VMS is capable of simulating conditions up to sea-state 5. The proof of concept experiment took place in September 2018 and demonstrated that the VMS can accurately simulate varying sea-states, collect performance data, and design a reliable and safe system for participants. The U.S. Coast Guard provided boat displacement data from the Large Amplitude Motion Program (LAMP). The program generates multi-directional waves with a cosine squared spreading function which produced a time history response of displacement data (surge, sway, heave, roll, pitch, yaw) of the OTH-IV's center of gravity (C.G). The displacement data was differentiated into acceleration evaluated at the crewmember's position at the front (bow) of the boat. Those accelerations were transformed to the VMS coordinate system and used as command inputs to the motion system's washout filters. The VMS uses Interchangeable Cabs (ICab) to perform flight simulations on a variety of aircraft or spacecraft configurations. An ICab typically contains seats, restraints, pilot controls, instrument panel, and out-the-window projectors all enclosed in a familiar cockpit configuration. To replicate the launch and recovery of a small boat, all the conventional features of a flight simulator and canopy were removed to be replaced with a to-scale OTH-IV bow mockup. The bow section was constructed from aluminum, and a connection point known as the davit ring. Additionally, a hook replica was suspended by a cable from the ceiling as if it were hanging from a davit crane aboard a cutter vessel. The last step was providing an auxiliary control to close the distance between suspended hook and the davit ring on the bow mockup. Without control the boat would simulate the wave motion, but with no guarantee that the crewmember will be in reach of the hook. Since the wave motion was repeatable, an additional acceleration command sent to the washout filters to move the simulator in the surge, sway, and heave directions, independently. The commands were rate limited such that the additional movement was not detectable with respect to the wave motion. The results showed that for each wave profile, a unique set of acceleration commands provided opportunities for crewmembers to gain control of the hook and connect it to the davit ring.

Riccobono, Nicholas S.↗

NASA NTRSDate not supplied

Pterodactyl: Guidance and Control of a Symmetric Deployable Entry Vehicle using an Aerodynamic Control System

The NASA-funded Pterodactyl project seeks to advance the state-of-the-art for varying entry vehicle types by developing unconventional guidance and control technologies for Deployable Entry Vehicles (DEVs) that can be applied to different entry vehicle configurations. Prior work by the authors [1–5] involved developing both traditional and novel integrated guidance and control solutions for a Pterodactyl Baseline Vehicle (PBV), a variant of an asymmetric DEV called the Lifting Nano ADEPT (LNA) [6]. In the prior studies, two different guidance schemes were designed and implemented for the PBV: (i) traditional bank angle guidance developed using the Fully Numerical Predictor-Corrector Entry Guidance (FNPEG) and (ii) novel angle of attack and sideslip (α - β) guidance developed using FNPEG with Uncoupled Range Control [4]. Using Linear Quadratic Regulator (LQR) optimal control methods with state-feedback integral control designs, these guidance trajectories were designed to be tracked using (i) a conventional propulsive entry vehicle control hardware architecture - reaction control systems (RCS) and (ii) novel non-propulsive entry vehicle control systems - aerodynamic flap control system (FCS) and moving mass control system (MMCS) [1]. The novel FCS and MMCS architectures were designed to track α - β guidance commands while the RCS was designed to track bank angle commands. It was discovered that the asymmetric DEV, the PBV, experienced a non-zero induced roll moment due to sideslip that the FCS and MMCS architectures had limited capability to trim out. These two architectures were designed to provide independent angle of attack and sideslip commands with limited consideration for roll moment generation to trim. As a result, for the PBV, the FCS and MMCS configurations as designed, were limited in providing the control authority needed to track an α - β guidance trajectory [1]. These results form the motivation for the work presented in this paper - utilizing an aerodynamic control system to track α - β guidance commands for a symmetric DEV with the expectation that a symmetric entry vehicle will have zero or significantly reduced roll moment due to sideslip that the FCS can handle when tracking an α - β guidance trajectory. To demonstrate the feasibility of a novel guidance and control architecture on a DEV, we utilize a symmetric DEV, the PBV-II, for (i) the novel α - β guidance development using FNPEG with Uncoupled Range Control and (ii) LQR control design using eight aerodynamic control surfaces. This paper demonstrates that the novel uncoupled α - β guidance tracking can be achieved using aerodynamic control surfaces on a symmetric deployable entry vehicle configuration.

Wendy A Okolo↗

NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗

NASA NTRS2020

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗

NASA NTRSDate not supplied

Firmware Architecture of the ARMADAS Bolting Robot

The Automated Reconfigurable Mission Adaptive Digital Assembly Systems (ARMADAS) project, under development at NASA Ames Research Center, has demonstrated on-ground autonomous robotic assembly of extensive digital structures, and it is now moving forward towards in-space demonstration. The ARMADAS system comprises of the operation software, the operation user interface (opsUI), and a swarm of robots. The robotic system consists of a multitude of collaborative agents specifically designed to transport, place and bolt the building blocks, called voxels (volumetric pixels). This paper focuses on the bolting robot, referred to as Mobile Metamaterial Internal Co-Integrator (MMIC-I). MMIC-I is a battery-powered crawling robot. It navigates the structure through extension, contraction and gripping. Two distinct controller boards operate the robot's two symmetric modules, referred to as module A and B. Board A is the master board: it coordinates motion planning and motion primitives execution, hosts the WiFi client, performs periodic self-assessment and system idle check and triggers faults if anomalies are detected. Board B periodically sends a heartbeat to board A, through a wired communication channel that uses the Serial protocol. Additionally, board A's WiFi client receives heartbeat packet requests or motion/bolting commands from a dedicated server board, and acknowledges reception sending back a response heartbeat packet containing information about the overall robot status, e. g. electrical current and voltage values, target and actual angles, operating mode, fault status. Whenever a motion command is sent, the motion planning section of the firmware determines the current robot configuration, using Inertial Measurement Unit readings and the motors Pulse Width Modulation values. Afterwards, it calculates the list of primitives needed to reach the target state, and controls their execution in the proper order. MMIC-I can receive and execute motion and bolting commands only when it is in operational mode. MMIC-I has three operating modes: standby, operational and safed. Standby mode is automatically entered upon startup. While in standby mode, all motors are powered off, and the only accepted commands are the ones relative to a change of mode and heartbeat packet request. Fault detection causes the robot to automatically enter safed or standby mode. Whenever the detected fault occurs within a motion and requires immediate intervention, e. g. an over-current situation, the robot enters safed mode. Safed mode powers off all motors except for the locomotion module, thus preventing the robot from collapsing. Conversely, when the detected fault doesn't require immediate intervention (low battery warning, for instance), the robot enters standby mode after completing the ongoing motion. This paper provides a detailed discussion of MMIC-I's firmware architecture. It accurately describes the implementation approach for each module: sensor data reading, motor control and actuation, WiFi server-client communication, intra-boards Serial communication, operating modes and autonomous fault detection, motion planning, coordination and execution, etc. Moreover, in support of the software description, this paper includes a thorough characterization of MMIC-I's hardware and avionics.

In-space assembly↗

NASA NTRSDate not supplied

VIPER Lunar Rover Agile Mission Systems

Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.

Agile↗

NASA NTRS2022

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

NASA NTRS2022

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

Roth, Brian↗

DOE OSTI2019

Secured control of circuit breakers in a digital substation

Methods and systems for secured control of circuit breakers in an electric power substation against undesired direct operation. Consequences of a malicious action are prevented or mitigated using a validation approach that either blocks the command or ensures a negligible effect on system operation. An example method, suitable for implementation in a monitoring device in an electric power substation, includes receiving a command to open or close a circuit breaker. In response, one or more state parameters for the electric power network that comprises the substation are then predicted, the predicted state parameters reflecting an operating state for the network under the assumption that the received command is executed. The method further comprises comparing the predicted one or more state parameters to corresponding operational limits. Execution of the command is then blocked, in response to determining that one or more of the predicted state parameters violate the corresponding operational limits.

Kondabathini, Anil↗

DOE OSTI2019

Joint speaker authentication and key phrase identification

A spoken command analyzer computing system includes technologies configured to analyze information extracted from a speech sample and, using a joint speaker and phonetic content model, both determine whether the analyzed speech includes certain content (e.g., a command) and to identify the identity of the human speaker of the speech. In response to determining that the identity matches the authorized user's identity and determining that the analyzed speech includes the modeled content (e.g., command), an action corresponding to the verified content (e.g., command) is performed by an associated device.

97 MATHEMATICS AND COMPUTING↗

DOE OSTI2021

Path-synchronous performance monitoring of interconnection networks based on source code attribution

Examples disclosed herein relate to path-synchronous performance monitoring of an interconnection network based on source code attribution. A processing node in the interconnection network has a profiler module to select a network transaction to be monitored, determine a source code attribution associated with the network transaction to be monitored, and issue a network command to execute the network transaction to be monitored. A logger module creates, in a buffer, a node temporal log associated with the network transaction and the network command. A drainer module periodically captures the node temporal log. The processing node has a network interface controller to receive the network command and mark a packet generated for the network command to be temporally tracked and attributed back to the source code attribution at each hop of the interconnection network traversed by the marked packet.

Chabbi, Milind M.↗