Engineering topics
Ingham, Mitch
Publications and source records attributed to Ingham, Mitch.
Behavior Ontology and Modeling Patterns for Spacecraft Power Analysis
No abstract available
Model-Based Design and Validation of Cellularized Satellites for the DARPA Phoenix Program
No abstract available
Engineering Resilient Space Systems: Introduction to Short Course
No abstract available
Modeling Off-Nominal Behavior in SysML
Fault Management is an essential part of the system engineering process that is limited in its effectiveness by the ad hoc nature of the applied approaches and methods. Providing a rigorous way to develop and describe off-nominal behavior is a necessary step in the improvement of fault management, and as a result, will enable safe, reliable and available systems even as system complexity increases... The basic concepts described in this paper provide a foundation to build a larger set of necessary concepts and relationships for precise modeling of off-nominal behavior, and a basis for incorporating these ideas into the overall systems engineering process.. The simple FMEA example provided applies the modeling patterns we have developed and illustrates how the information in the model can be used to reason about the system and derive typical fault management artifacts.. A key insight from the FMEA work was the utility of defining failure modes as the "inverse of intent", and deriving this from the behavior models.. Additional work is planned to extend these ideas and capabilities to other types of relevant information and additional products.
Timeline and the Timeline Exchange Infrastructure: A Framework for Exchanging Temporal Information
No abstract available
MBSE in Development: SMAP Pilot Project
Customer-focused objective: Provide value to a flight project using Model-Based Systems Engineering (MBSE) methodology and products. Institution-focused objective: Advance and improve our systems engineering practices, leveraging MBSE where applicable: Streamline our interfaces across JPL Divisions, to provide better cross-organization products; Streamline our interfaces across lifecycle phase boundaries; Update our SE practices to make them more competitive and able to handle systems of ever-increasing complexity.
Preliminary Design of the Guidance, Navigation, and Control System of the Altair Lunar Lander
Guidance, Navigation, and Control (GN&C) is the measurement and control of spacecraft position, velocity, and attitude in support of mission objectives. This paper provides an overview of a preliminary design of the GN&C system of the Lunar Lander Altair. Key functions performed by the GN&C system in various mission phases will first be described. A set of placeholder GN&C sensors that is needed to support these functions is next described. To meet Crew safety requirements, there must be high degrees of redundancy in the selected sensor configuration. Two sets of thrusters, one on the Ascent Module (AM) and the other on the Descent Module (DM), will be used by the GN&C system. The DM thrusters will be used, among other purposes, to perform course correction burns during the Trans-lunar Coast. The AM thrusters will be used, among other purposes, to perform precise angular and translational controls of the ascent module in order to dock the ascent module with Orion. Navigation is the process of measurement and control of the spacecraft's "state" (both the position and velocity vectors of the spacecraft). Tracking data from the Earth-Based Ground System (tracking antennas) as well as data from onboard optical sensors will be used to estimate the vehicle state. A driving navigation requirement is to land Altair on the Moon with a landing accuracy that is better than 1 km (radial 95%). Preliminary performance of the Altair GN&C design, relative to this and other navigation requirements, will be given. Guidance is the onboard process that uses the estimated state vector, crew inputs, and pre-computed reference trajectories to guide both the rotational and the translational motions of the spacecraft during powered flight phases. Design objectives of reference trajectories for various mission phases vary. For example, the reference trajectory for the descent "approach" phase (the last 3-4 minutes before touchdown) will sacrifice fuel utilization efficiency in order to provide landing site visibility for both the crew and the terrain hazard detection sensor system. One output of Guidance is the steering angle commands sent to the 2 degree-of-freedom (dof) gimbal actuation system of the descent engine. The engine gimbal actuation system is controlled by a Thrust Vector Control algorithm that is designed taking into account the large quantities of sloshing liquids in tanks mounted on Altair. In this early design phase of Altair, the GN&C system is described only briefly in this paper and the emphasis is on the GN&C architecture (that is still evolving). Multiple companion papers will provide details that are related to navigation, optical navigation, guidance, fuel sloshing, rendezvous and docking, machine-pilot interactions, and others. The similarities and differences of GN&C designs for Lunar and Mars landers are briefly compared.
Trusted Autonomy for Space Flight Systems
NASA has long supported research on intelligent control technologies that could allow space systems to operate autonomously or with reduced human supervision. Proposed uses range from automated control of entire space vehicles to mobile robots that assist or substitute for astronauts to vehicle systems such as life support that interact with other systems in complex ways and require constant vigilance. The potential for pervasive use of such technology to extend the kinds of missions that are possible in practice is well understood, as is its potential to radically improve the robustness, safety and productivity of diverse mission systems. Despite its acknowledged potential, intelligent control capabilities are rarely used in space flight systems. Perhaps the most famous example of intelligent control on a spacecraft is the Remote Agent system flown on the Deep Space One mission (1998 - 2001). However, even in this case, the role of the intelligent control element, originally intended to have full control of the spacecraft for the duration of the mission, was reduced to having partial control for a two-week non-critical period. Even this level of mission acceptance was exceptional. In most cases, mission managers consider intelligent control systems an unacceptable source of risk and elect not to fly them. Overall, the technology is not trusted. From the standpoint of those who need to decide whether to incorporate this technology, lack of trust is easy to understand. Intelligent high-level control means allowing software io make decisions that are too complex for conventional software. The decision-making behavior of these systems is often hard to understand and inspect, and thus hard to evaluate. Moreover, such software is typically designed and implemented either as a research product or custom-built for a particular mission. In the former case, software quality is unlikely to be adequate for flight qualification and the functionality provided by the system is likely driven largely by the need to publish innovative work. In the latter case, the mission represents the first use of the system, a risky proposition even for relatively simple software.
MDS overview and demonstration
Explore the source record for details and available documents.