JPL
Careers
Education
Science & Technology
JPL Logo
JPL Logo

Downloaded from websites across the globe, 8 million PDFs have been assembled by JPL data scientists into an archive representing the largest sample of the file type. Researchers can use the archive to better understand online threats, address privacy vulnerabilities, and identify software compatibility problems.

Credit: Adobe Stock/Science RF
Mission Data System
Architecture
System Engineering
Software
Documents
Contact
Publications

Architecture

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.

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. SOFTWARE 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.

CL#26-2091

About JPL
Who We Are
Directors
Careers
Internships
The JPL Story
JPL Achievements
Documentary Series
JPL Annual Report
Executive Council
Missions
Current
Past
Future
All
News
All
Earth
Solar System
Stars and Galaxies
Eyes on the News
Subscribe to JPL News
Galleries
Images
Videos
Audio
Podcasts
Apps
Visions of the Future
Slice of History
Robotics at JPL
Events
Lecture Series
Speakers Bureau
Calendar
Visit
Public Tours
Virtual Tour
Directions and Maps
Topics
JPL Life
Solar System
Mars
Earth
Climate Change
Exoplanets
Stars and Galaxies
Robotics
More
Asteroid Watch
NASA's Eyes Visualizations
Universe - Internal Newsletter
Social Media
Accessibility at NASA
Contact Us
Get the Latest from JPL
Follow Us

JPL is a federally funded research and development center managed for NASA by Caltech.

More from JPL
Careers
Education
Science & Technology
Acquisition
JPL Store
Careers
Education
Science & Technology
Acquisition
JPL Store
Related NASA Sites
Basics of Spaceflight
NASA Kids Science - Earth
Earth / Global Climate Change
Exoplanet Exploration
Mars Exploration
Solar System Exploration
Space Place
NASA's Eyes Visualization Project
Voyager Interstellar Mission
NASA
Caltech
Privacy
Image Policy
FAQ
Feedback
Version: v3.1.3 - 5e83a9a
Site Managers:Emilee Richardson, Alicia Cermak
Site Editors:Steve Carney
CL#:21-0018