Skip to main content
The AIG web pages make heavy use of cascading style sheet features for formatting. You may still browse the text of the site, but for best results, please use a CSS enabled browser. Netscape 6 and Mozilla 5 are good. IE 5 will do.

JPL Header



Navigation Sidebar



Main Content


Technology
Mission Data System

Technology Mission Data System Banner

MDS Architecture

The MDS Control System Architecture focuses on the physical states a control system is being designed to manage, and on the interactions among those states. A strict boundary is drawn between the control system being designed, and the target system under control. For every state of interest in the system under control, a state variable is defined to reflect its value. A physical state variable denotes the abstract modeled state of the system under control, while a software state variable provides both the control system's explicit knowledge (estimates) of the physical state as well as the control system's intent against that physical state. Modeled physical state variables are used in descriptions of the system under control and may also appear in analyses or simulations of it. Software state variables become part of the control system implementation in MDS framework adaptations.

A software state variable is primarily a container for a timeline of state values, ensuring system-wide consistency, and providing a uniform, time-indexed interface to consistent values for all other elements of the control system needing those values. Knowledge values are interpolated over time and can be set statically (e.g., constant parameters), derived from other states, or estimated from available evidence by an Estimator. Available evidence can be in the form of received Measurements, monitored Commands, or other state knowledge values. Physical states that can be controlled can also have a Controller in the control system whose job it is to monitor state knowledge and issue appropriate Commands to the system under control in order to change the state of the system under control. The actions of controllers are governed by state intent, which is also contained in software state variable timelines. Similarly, the activities of estimators are also governed by intent, which constrains the quality of state knowledge. Because they attempt to achieve intent, controllers and estimators are referred to collectively as Achievers.

States variables and their controllers and estimators interact with one another according to shared Models of the physical system. Models provide formal descriptions of the physical system, suggesting how its state can be represented and estimated from available evidence, and how it can be controlled.

MDS Architecture

Intent is expressed through Goals. Goals define, not just what operators intend, but also what conditions they wish to avoid, thus integrating nominal control and fault protection into the same framework. A goal is a constraint on the history of state knowledge over some interval of time. An estimator's job is to achieve a given goal on knowledge quality by collecting sufficient evidence and processing it appropriately. A controller's job is to try to achieve a given goal on controlled behavior by issuing the commands needed to keep the given state within the given constraint. Goals are different from commands in that a goal expresses intent continually over a given time interval, allowing the control system to verify at all times whether operational and safety intent is being achieved, and to respond if it isn't. Consequently, all control behavior at all levels is closed-loop.

The MDS architecture defines rules for combining goals into complex activities, called Goal Networks, and for elaborating and scheduling consistent and achievable networks. These rules are defined in such a way that they can be encoded in the control system software for automatic generation and execution, enabling the control system to automatically plan complex activities, and re-plan activities in the event of a fault or other disruption (resource issues, environmental changes, discovered opportunities, and so on).

While the MDS control system architecture is intended to help guide the development of software-based control systems, these principles could also extend to parts of a system implemented in hardware. Frameworks implementing the basic software patterns specified in the architecture have been implemented in C++ and Java, although the architecture itself is abstract, and language neutral.


+ back to MDS Home


Contact Information

Kenny Meyer

M/S 301-225
4800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.393.4871
kenny.meyer@jpl.nasa.gov

Bob Rasmussen

M/S 301-225
4800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.354.2861
robert.d.rasmussen@jpl.nasa.gov


LEGAL NOTICE

All MDS Framework artifacts and State Analysis artifacts except for source code and object code have been designated by the California Institute of Technology (Caltech) as Technology and Software Publicly Available (TSPA). Copyright 2005. The copyrights and patents related to this technology are owned by Caltech. United States Government sponsorship acknowledged.

Footer



CL 07-3583