The notion of Timeline has been used informally in spacecraft operations software for some time, but it has not heretofore been formalized and unified either syntactically or semantically. In this work, the Timeline has been formalized and unified so that the commonality can be exploited to reduce the cost of developing and using spacecraft operations software. The Timeline can then be used as the common data structure for storage and communications between spacecraft planning and operations software elements.
Most spacecraft planning and operations processes are naturally expressed in terms of software tools that read timelines from databases as input and generate results as new or modified timelines that are written to the databases. Timelines are rigorously versioned, and each version is immutable — thus, a versioned timeline name forever represents exactly the same contents. The name is therefore as good as the contents, and the need for keeping files of contents for communicating between programs, or for associating several timelines or even values on those timelines, or for keeping a record of past values, is eliminated. Timelines thus form the syntactic and semantic method of integration of software elements, leading to decreased adaptation cost.
Operations efficiency is increased because historically segregated elements are easily integrated so that there are fewer gaps in the operations process that must currently be closed, if they are closed at all, by expensive or inefficient means.
The Timeline is abstractly defined as a container of items indexed by time, or of items related by time. The abstract definition is intentionally rather open, and the edge between timeline and not-timeline is fuzzy. The abstract definition does not need to be formalized, because it is the type of timeline that is actually defined that has practical impact. Timelines are made practical by creating concrete types of timelines that can be precisely defined, stored in databases, manipulated in software, and so on.
Timeline instances are stored in timeline databases (TLDBs). All TLDB instances must have two properties beyond the obvious of providing for the storage and retrieval of timelines: they must be rigorously versioned, meaning that in principle every change to a timeline creates a new version of that timeline; and they must provide version immutability, meaning that once a version is created, it is never changed. The reason for this is so that a timeline name and version together precisely represent the contents of that timeline at some instant in time.
The Database Interface is a key architectural invariant, along with the Timeline. It is designed to allow the database technology to be selected to meet mission needs. For example, a small mission may choose to use a free database. A larger mission may choose to use a commercial database that provides robust hot backups, offsite mirroring, local caching, and the like. A mission may choose to put the data in a commercial cloud. It may even change DB technologies over the life of the mission, using something cheap and light in formulation, heavy in operations, and optimized for archival access in perpetuity. The interface stays the same no matter what technology is used by a project, so that the spacecraft operations software suite will operate the same regardless of the DB technology used.
Interfaces can be added and extended, so that when a new timeline major type is introduced, the interfaces can be systematically extended to support the new timeline type.
This work was done by William K. Reinholtz of Caltech for NASA’s Jet Propulsion Laboratory.