About Nexus

Nexus is the planning and scheduling system for tomorrow’s space missions.

Nexus is at the frontier of the planning and scheduling technology.  As we explore further from home, resources will become more scarce, tasks will become more complex and the need for autonomy will increase.  Nexus is the

Nexus is the enabling technology!

technology to enable these missions to be more autonomous.  It will allow multiple planners, some on the earth and some in space, to build one integrated schedule; it can capture all the task requirement so that schedules can be built automatically; it can reduce cost by allowing those with the best knowledge of the tasks to schedule them; and its architecture is flexible and scalable to allow installation at remote sites.

At the heart of Nexus technology is a robust scheduling engine we call the Scheduling Algorithm for Temporal Relation Networks (SATRN).  It takes detailed task requirements and locates times in the schedule where the requirements are met.  This crucial component enables task experts to concentrate on describing and placing tasks instead of worrying about the details of scheduling.

Usage

Multi-user— Multiple users can simultaneously build a single timeline through a centralized scheduling server.   Users only need a computer and an Internet connection – even astronauts on orbit.  This can enable those closest to the tasks being performed to enter their requirements and build the best schedule for themselves.  The current Nexus development architecture is this configuration and we call it the Request-Oriented Scheduling Environment (ROSE) configuration.

Standalone— One user, on a single computer, working on one schedule is the classical configuration for planning and scheduling systems.  This configuration would be the simplest setup of Nexus.

Personal Data Assistant— Crew self planning is an additional interface planned for Nexus. An astronaut could plan their own day rather than the traditional remote planning done today.

Imagine

Imagine astronauts using their PDA to contact the lunar habitat to see what their "to-do" list is or to pull up an item from their "job jar," submitting it to the scheduler, and seeing the resulting schedule.  Unlike job-jar tasks on today's space station, these job-jar tasks could use scarce resources.

The scheduling engine would be installed in the habitat (so the astronauts don't have to wait on the 2.5 second round-trip light-speed delay for communications with the earth).  Using the remote access capabilities of Nexus, ground experts on earth would model the lunar systems.  Task modeling would be done by those – astronauts, scientists, technicians, controllers – with the best knowledge of the tasks.  The timeline would be monitored by ground controllers and visual validation would augment the built-in logic. built-in logic.

Key Features

• Comprehensive Modeling— Nexus models can fully describe the complexity of operations performed on a space platform.
• Innovative Scheduling Engine— The Nexus scheduling engine understands the models and can automatically schedule them.
• Building-block Architecture— Nexus architecture is flexible and extensible.

Each of these key features is discussed below.

Comprehensive Modeling

The capability of a scheduling system is dependent on the quality of the input — the models of the tasks to be scheduled.  Nexus models are maximally expressive.  The modeling schema is a true advancement in the state of the art.

• Decomposition into salient components— Modeling is based on activities and sequences; (see same titled section below).
• Equipment modes— Implicit resource requirements are defined by equipment mode models, closely representing the real world.
• Intuitive and rich expression of the relationships between components— Modeling employs common-sense modeling of temporal relationships using everyday concepts like sequential, during, and overlap.  Innovative modeling of the continuance of resource usage between tasks, the fragmentation of tasks, and minimal percent coverage is included.
• Public Services— Modeling also includes the concept of public services, models that are scheduled at the request of another model.
• Experiment flexibility— Variable timing can be modeled at all levels. Alternate resources and sequences of elements can be modeled.
• Representation of nuances of the tasks— Even nuances, such as locking in alternate resources and one-to-one relationships are available.

Decomposition into salient components

Nexus uses “activities” and “sequences” to build scheduling requests.

• Activities define the resource requirements (with alternatives) and other quantitative constraints of tasks to be performed.
• Sequences define the relationships between activities. Sequences may also define relationships with other sequences and with activities and sequences of other payloads and platform or vehicle systems.

Nexus uses graphics methods to build requests.

Activities are defined by an “outline” graphics paradigm. Requirements may be grouped into “all-of” groups or “1-of” groups.  Groups may be arranged in a hierarchy. Drag-and-drop is used to define the hierarchy.  Constraints are selected from predefined lists.  The values of constraints are entered via dialog boxes.

Sequences are described by a “network” graphics paradigm. The spatial location is used only as a visual aide; actual temporal constraints are entered via dialog boxes associated with the markers on the connecting lines. Relationships include “during,” “sequential,” “separated,” “overlap,” “standby,” “percent coverage,” “fragmentable,” and “cyclic.”

– The scientist, the technicians and the astronauts are the experts on the tasks to be performed. – After only a few submittals, they will know what to expect from the scheduler; i.e., they will become virtual experts on the scheduling environment. – Using Nexus, they can produce the schedule they want – the best schedule.

 

Innovative Scheduling Engine

Nexus uses the Scheduling Algorithm for Temporal Relation Networks (SATRN) as an “incremental” scheduler.  SATRN processes a single request (adding one or more tasks to the timeline) and then waits for another request.

SATRN converts the temporal relations of a sequence to time bounds on the sequence entities (embedded sequences or activities). As each entity is scheduled, the bounds on not-scheduled entities are shrunk.  An activity’s requirements are checked by a depth-first search. Variable activity durations are utilized to stay within the time bounds.  When an entity cannot be scheduled, smart backtracking and reordering is used to unshrink the bounds on hard-to-schedule entities. Backtracking is also used to explore alternate requirements (“1-of” groups, scenarios, optional entities, and relationships to existing entities with multiple instances).

SATRN was developed to match the modeling methodology.  Nexus uses recursion to process embedded sequences and constraint hierarchies.

Building-Block Architecture

Nexus is being developed using a state-of-the-art software development processes called “Scrum”.  Scrum is an agile version of the spiral life-cycle model. Improvements within each spiral are driven by the Capability Maturity Model®.  Nexus is being created with the latest technologies from the Microsoft .NET Framework® such as the C# object oriented programming language, .NET Remoting, web services and the "managed" Common Language Runtime Environment.  Maximum code reuse is a goal.

The data in Nexus is stored in a relational database; a no-cost database is used for small installations.  XML interfaces are used for system interoperability with future mission systems.

The components of Nexus are being developed for optimal configurability.  The architecture can be scaled as needed and can be configured on a standalone computer or can be a 3-tiered web application.

The diagram below shows how the modules of Nexus are interconnected.  Below the diagram is a description of each module.

Modules

Constraint Modeling— Define constraints (including infrastructure) that limit the timelines and plans.  Import availabilities and allocations.

Task Modeling— Enter/edit models of the tasks to be scheduled.

Planning and Scheduling— State-of-the-art system that schedules tasks at times when they are useful, while efficiently sharing scarce resources and within infrastructure and allocation constraints.

Timeline Editor— Graphically manipulate the task timeline. It reports introduced conflicts and suggests non-confliction times.

Scheduling Engine— Automated incremental scheduling engine.

Report Generation— Generate reports about constraints and tasks to be scheduled, & the resulting timelines and plans for the tasks and infrastructure.  Export timelines.

Timeline Integration— Integrate timelines and all associated data (tasks, constraints, etc.). 

Infrastructure Planning— Generate infrastructure plans to support task plan.

Constraint Database— Models of the limitations of the operating environment against which tasks are modeled and which restrict how timelines and plans are constructed.

Tasks Database— Models of the steps that need to be performed and requirements that need to be met in order to accomplish an objective.

Timelines and Plans Database— Timetables of how the infrastructure will be used to support the task plans.

The Space Activity Domain

Nexus is designed to schedule tasks that would be done on a space platform – most likely a manned space platform.  The table below compares the target Nexus domain with the "job-shop" or manufacturing domain.

The Nexus Vision

Planning for human space missions has always been labor intensive; during Skylab it was done with charts hand-drawn on paper, now it is done manually with the aid of computer-based timeline editors.  Several “automatic” schedulers have been written, but none have been truly successful.  The goal of Nexus is to define a scheduling engine that enables the migration to planning and scheduling paradigms which have as their central tenant the use of an automatic scheduler.

The current state of the art in modeling methodologies and scheduling engines results in a linear paradigm with knowledge contributed by task experts, vehicle experts and scheduling engine experts.  This paradigm, show above, requires significant effort and flow time.  Using a system like Nexus, the task experts can then enter their requirements directly into the scheduling engine.  A scheduling engine is being built which understands the requirements as presented by the task experts and eliminates the need for scheduling experts.  This paradigm is shown below.

Simply stated, the Nexus vision is

To enable the migration from the conventional paradigm to a new and better paradigm.