Engineering Papers⌕ Search

Engineering topics

Jones, Grailing

Publications and source records attributed to Jones, Grailing.

Architecture Modeling on the Europa Project

In 2015 NASA chartered a partnership between the Jet Propulsion Laboratory (JPL) and the Johns Hopkins Applied Physics Laboratory (APL) to begin planning a mission to study the Jovian moon Europa. The project has adopted a Model-Based Systems Engineering (MBSE) approach to its architecting process since its early formulation, developing certain modeling practices and tools as needed, with the expectation that this process would result in a more consistent and verifiable architecture than with a more traditional document-based approach. A sound architecture is essential to provide the rationale for requirements on the system design, and to define the trade space of acceptable design points within which technical and programmatic concerns as well as project objectives can be addressed. This paper provides an overview of the framework used by the Europa project to describe the mission architecture and discusses how a system model was instrumental in providing a single-source-of-truth for this description. Several key modeling patterns to represent the architecture are presented, along with audit methods to ensure the consistency and the correctness of the model. Finally, the benefits and challenges of using a model-based approach to generate traditional requirements documents and other gate products are assessed.

Dubos, Gregory F.↗

Adapting ASPEN for Orbital Express

By studying the Orbital Express mission, modeling the spacecraft and scenarios, and testing the system, a technique has been developed that uses recursive decomposition to represent procedural actions declaratively, schema-level uncertainty reasoning to make uncertainty reasoning tractable, and lightweight, natural language processing to automatically parse procedures to produce declarative models. Schema-level uncertainty reasoning has, at its core, the basic assumption that certain variables are uncertain, but not independent. Once any are known, then the others become known. This is important where a variable is uncertain for an action and many actions of the same type exist in the plan. For example, if the number of retries to purge pump lines was unknown (but bounded), and each attempt required a sub-plan, then, once the correct number of attempts required for a purge was known, it would likely be the same for all subsequent purges. This greatly reduces the space of plans that needs to be searched to ensure that all executions are feasible. To accommodate changing scenario procedures, each is ingested into a tabular format in temporal order, and a simple natural-language parser is used to read each step and to derive the impact of that step on memory, power, and communications. Then an ASPEN (Activity Scheduling and Planning Environment) model is produced based on this analysis. The model is tested and further changed by hand, if necessary, to reflect the actual procedure. This results in a great savings of time used for modeling procedures. Many processes that need to be modeled in ASPEN (a declarative system) are, in fact, procedural. ASPEN includes the ability to model activities in a hierarchical fashion, but this representation breaks down if there is a practically unbounded number of sub-activities and decomposition topologies. However, if recursive decomposition is allowed, HTN-like encodings are enabled to represent most procedural phenomena. For example, if a switch requires a variable (but known at the time of the attempt) number of attempts to switch on, one can recurse on the number of remaining switch attempts and decompose into either the same switching activity with one less required attempt, or not decompose at all (or decompose into a dummy task), resulting in the end of the decomposition. In fact, any bounded procedural behavior can be modeled using recursive decompositions assuming that the variables impinging the disjunctive decomposition decision are computable at the time that the decision is made. This enables one to represent tasks that are controlled outside of the scheduler, but that the scheduler must accommodate, without requiring one to give a declarative model of the procedural behavior.

Chouinard, Caroline↗

Automated and Adaptive Mission Planning for Orbital Express

The Orbital Express space mission was a Defense Advanced Research Projects Agency (DARPA) lead demonstration of on-orbit satellite servicing scenarios, autonomous rendezvous, fluid transfers of hydrazine propellant, and robotic arm transfers of Orbital Replacement Unit (ORU) components. Boeing's Autonomous Space Transport Robotic Operations (ASTRO) vehicle provided the servicing to the Ball Aerospace's Next Generation Serviceable Satellite (NextSat) client. For communication opportunities, operations used the high-bandwidth ground-based Air Force Satellite Control Network (AFSCN) along with the relatively low-bandwidth GEO-Synchronous space-borne Tracking and Data Relay Satellite System (TDRSS) network. Mission operations were conducted out of the RDT&E Support Complex (RSC) at the Kirtland Air Force Base in New Mexico. All mission objectives were met successfully: The first of several autonomous rendezvous was demonstrated on May 5, 2007; autonomous free-flyer capture was demonstrated on June 22, 2007; the fluid and ORU transfers throughout the mission were successful. Planning operations for the mission were conducted by a team of personnel including Flight Directors, who were responsible for verifying the steps and contacts within the procedures, the Rendezvous Planners who would compute the locations and visibilities of the spacecraft, the Scenario Resource Planners (SRPs), who were concerned with assignment of communications windows, monitoring of resources, and sending commands to the ASTRO spacecraft, and the Mission planners who would interface with the real-time operations environment, process planning products and coordinate activities with the SRP. The SRP position was staffed by JPL personnel who used the Automated Scheduling and Planning ENvironment (ASPEN) to model and enforce mission and satellite constraints. The lifecycle of a plan began three weeks outside its execution on-board. During the planning timeframe, many aspects could change the plan, causing the need for re-planning. These variable factors, ranging from shifting contact times to ground-station closures and required maintenance times, are discussed along with the flexibility of the ASPEN tool to accommodate changes to procedures and the daily or long-range plan, which contributed to the success of the mission. This paper will present an introduction to ASPEN, a more in-depth discussion on its use on the Orbital Express mission, and other relative work. A description of ground operations after the SRP deliveries were made is included, and we briefly discuss lessons learned from the planning perspective and future work.

scheduling↗

Orbital Express Mission Operations Planning and Resource Management using ASPEN

The Orbital Express satellite servicing demonstrator program is a DARPA program aimed at developing "a safe and cost-effective approach to autonomously service satellites in orbit". The system consists of: a) the Autonomous Space Transport Robotic Operations (ASTRO) vehicle, under development by Boeing Integrated Defense Systems, and b) a prototype modular next-generation serviceable satellite, NEXTSat, being developed by Ball Aerospace. Flexibility of ASPEN: a) Accommodate changes to procedures; b) Accommodate changes to daily losses and gains; c) Responsive re-planning; and d) Critical to success of mission planning Auto-Generation of activity models: a) Created plans quickly; b) Repetition/Re-use of models each day; and c) Guarantees the AML syntax. One SRP per day vs. Tactical team

automated planning scheduling↗

Orbital Express Mission Operations Planning and Resource Management using ASPEN

As satellite equipment and mission operations become more costly, the drive to keep working equipment running with less man-power rises.Demonstrating the feasibility of autonomous satellite servicing was the main goal behind the Orbital Express (OE) mission. Planning the satellite mission operations for OE required the ability to create a plan which could be executed autonomously over variable conditions. The Automated-Scheduling and Planning Environment (ASPEN)tool, developed at the Jet Propulsion Laboratory, was used to create the schedule of events in each daily plan for the two satellites of the OE mission. This paper presents an introduction to the ASPEN tool, the constraints of the OE domain, the variable conditions that were presented within the mission, and the solution to operations that ASPEN provided. ASPEN has been used in several other domains, including research rovers, Deep Space Network scheduling research, and in flight operations for the ASE project's EO1 satellite. Related work is discussed, as are the future of ASPEN and the future of autonomous satellite servicing.

Automated Scheduling and Planning Environment (ASP↗