NASA Ames, in collaboration with Johnson Space Center (JSC), has built a set of frameworks to enable mission operations software systems to be assembled from flexible collections of components and services. Components may be assembled and modified by users, with the level of composability and permissions controlled by policies. By assembling systems from components on a common framework, the traditional “walls” of monolithic applications are eliminated, as are the heterogeneous code bases and functional overlaps that come with traditional software applications. User composition empowers users to make rapid changes to software, within the constraints of organizational policy, without the need for code changes from platform service providers. In turn, platform service providers have the capability to provide certified, yet flexible systems.
Mission Control Technologies (MCT) is an extensible architecture that was developed as a generic framework for developers and deployed with a specific set of modules as an application at JSC. Traditional software is built as monolithic applications. The functionality of an application is determined during design and development. Once an application is developed and tested, change is difficult, leaving users with few options other than operational workarounds, if the software does not do what is needed. Recent software systems have evolved away from monolithic applications to collections of components and services. This model leaves organizations with a more effective way to customize and reuse software.
MCT brings object orientation to the user interface, presenting users with a graphical user interface that is both object oriented and composable. Rather than interacting with traditional applications, users interact with user objects, which they can compose on screen to function as needed, without requiring another application for creating compositions. Compositions can be managed by policies. This provides a mechanism to implement organizational policies in software.
The MCT system is normally deployed among a set of workstations with a consistent configuration. In this environment, user objects may be shared among different users so that all see the system consistently. It is also possible to run MCT on a single workstation without object sharing.
In an MCT application, systems are modeled the way users think of them. User objects are “things” that users can manipulate on screen, and are designed to mirror the data and behavior of their real-world counterparts. Each user interface entity is its own object, and behaves in consistent, predictable ways.
MCT user objects share two key features:
Custom displays or systems in MCT are built out of objects that all look and act the same way. Functionality of the system is expanded or changed by simply adding new objects, views, or data sources. Any new object will be consistent with the environment and all existing objects, a new menu will work exactly the same way as existing menus, new views will act the same way as existing views, and so on.
Each user object is characterized by a set of core properties and behaviors, but users never see the actual object itself—what they see are manifestations of it that display the information or a portion of the information contained in that object, presented in a particular format. Looking at different views of an object is like going between the page layout and outline views in a word processor’s window, or comparing the displayed page and the source code in a web browser.
A manifestation of a user object is not a separate, independent instance of that object; it is a live representation of the underlying object, and changes made to the object from any of its manifestations will be reflected in all manifestations of that object. Different users of the system always see the same user objects consistently.
MCT displays are compositions of user objects. Users can compose user objects in any way allowed by policy, and user objects from multiple domains or data sources may be composed as needed. Because each user object’s appearance on the screen is a manifestation of the same underlying “thing,” different manifestations of the same user object can be used in different places at the same time. Collections of user objects are themselves user objects, and share the characteristics of all MCT user objects.
Through policies, developers or administrators can exercise control over the actions permitted to users at any level of granularity desired. MCT is designed for interoperability and flexibility, but all aspects of the framework (user objects, views, compositions, etc.) can be configured to be as loosely or tightly controlled as operating conditions or security restraints require. Policies can apply to individual users, groups of users, or MCT collections and other objects.
MCT has built-in policies to cover general cases that coordinate performance of the user interface. It is expected that customers and developers will customize these policies to meet their own safety and security requirements.
MCT is now deployed in the Johnson Space Center Mission Control Center, where it is certified for International Space Station operations. The initial MCT deliveries provide functionality for telemetry and monitoring, providing flight controllers with a composable user interface that allows them to build their own monitoring displays, and provide developers with a toolkit for adding functions onto MCT’s modular architecture.
The first releases of the MCT
application to JSC contain a selection of ISS telemetry elements and
several different views for displaying the retrieved data that provide
some of the functionality that currently exists in existing MCC tools. MCT objects could just as easily be physical parts,
procedures, steps in a procedure, or documents—any of these
would be treated in exactly the same way as user objects by MCT. Later
JSC releases will add capabilities and object types for additional flight
controller tasks. Third-party developers can write plugins to add commanding and controlling functions.
MCT received the JSC Director's Innovation Award in July, 2011.
Programming for the MCT platform is primarily Java-based, with some selective use of XML. Standard Swing code is used to create the user interface display and interactions. MCT follows standard Java look and feel guidelines, and is compatible across the Linux, Mac OS, and Windows platforms.
To the user, the MCT system represents elements of the users’ problem domain as user objects. User objects are “things” that users can manipulate, and are designed to mirror the data and behavior of their real-world counterparts. For example, a sensor on the ISS might be represented within MCT as a user object that holds the current sensor value and can be displayed as a number, a graph through time, or a value on a timeline. A user object is a conceptual entity, meaning there is no direct correspondence between the user object and the code written to implement it. At the implementation level, user objects are made up of one or more MCT components.
The MCT platform is easily adaptable to other users and missions. MCT developers can extend the system by adding new MCT plugins, which provide new components, policies, or other services. All MCT user objects behave similarly, no matter whether they are part of the base MCT system or domain-specific components added by developers.
The MCT framework was released to the open source community on May 9, 2012 under the Apache 2.0 license.
One of MCT’s greatest strengths is the ability to customize its features and user interface for different uses and domains. MCT was developed both as a generic framework with standard plugins for developers, and as a custom application with specific plugins for JSC. ISS telemetry monitoring was chosen as the first domain-specific feature implemented, to demonstrate to JSC flight controllers MCT’s ability to interface with external services and display the retrieved data in multiple forms. Domain-specific features are developed exactly the same way as generic features, and developers who want to use MCT for very different purposes can use the telemetry components as models for how they could develop other categories of domain-specific features.
All MCT customizations requiring additional code are installed as plugins. Extensions to the base set of MCT components and services are developed and deployed using the OSGi module system. OSGi is an open standard which defines an architecture for modular applications that can be managed on the fly throughout their entire lifecycle. Individual components can be installed, started, stopped, updated, and uninstalled without restarting the entire system. In OSGi, software is deployed in the form of a bundle, a self-contained unit that declares its dependencies on other resources and exposes services it provides. A plugin should provide one or more OSGi services. The particular services the plugin should provide depend on the purpose of the plugin. A component needs to supply at least one view, but most components will want to supply more than one.
OSGi provides a service registry to manage interaction between the container and the bundles as well as between bundles. It supports dynamic loading and updates to modules to provide flexibility. In addition, the OSGi framework provides standard services such as event handling and configuration that reduce the burden on the developer.
Learn More >