Special Notice

NASA/ARC plans to issue a Request for Proposals due after September 30, 2002 for co-operative agreements for research on High-Dependability Computing testbeds for software-based systems. This solicitation is related to the NSF solicitation on Highly Dependable Computing and Communication Systems Research, whose proposals are due early summer, 2002. The NASA solicitation will be limited to parties that are selected to receive an award under the NSF solicitation.

Description

NASA/ARC has a requirement for research on highly dependable software-based systems. Under a co-operative agreement with CMU (http://www.amesnews.arc.nasa.gov/releases/2002/02_03AR.html), testbeds are being set up at NASA Ames Research Park that will be accessible on-site and remotely. The testbeds are closely related to significant NASA software systems, and will provide a means to develop methods for predicting the dependability of software-based systems and to empirically validate technology for improving the dependability of such systems.

This web site will be updated periodically to provide information on the testbeds and the proposal process for cooperative agreements. A solicitation was sent out internally within NASA in February for testbed artifact proposals, and received an enthusiastic response. Two primary testbeds have been selected, representing the broad areas of dependable networks for flight and component-based software for mission-critical systems. The testbeds are expected to included artifacts that are analogues to real NASA systems, as described below. Some dependability questions that could be investigated with these testbeds are suggested, though researchers are not limited to these particular questions.

Technical Point of Contact : Michael R. Lowry

      Title: High-Dependability Computing Program Manager

      Phone: (650) 604-3369

      Fax: (650) 604-3594

      Email: mlowry@mail.arc.nasa.gov

      Procurement Point of Contact: Carlos D. Torrez

      Title: Contracting Officer

      Phone: (650) 604-5797

      Fax: (650) 604-3020

      Email:  ctorrez@mail.arc.nasa.gov

Dependable Networks for Flight Testbed

1. Overview and Importance to NASA

Distributed information networks arise in many critical aerospace contexts, including mission control for manned and unmanned missions, air traffic control, and increasingly onboard aerospace vehicles. This testbed is expected to be an analogue of a network that is currently being designed for the international space station. The testbed might also draw upon other aerospace networks. The International Space Station (ISS) Program Office at Johnson Space Center (JSC) in Houston has initiated a project to define and build an On-board Information Technology (OIT) infrastructure for supporting crew and payload operations. This OIT system consists of LAN resources, servers, client devices and commercial and custom software. It is used for mission support and has specific interfaces to Station avionics systems, but is not directly flight-critical at this time. The ISS Program hopes to evolve OIT dependability to a point where higher criticality functions can be migrated off of the current custom avionics platforms onto the OIT infrastructure. The OIT is an ideal candidate for insertion of commercial IT solutions, requiring at least enterprise-level dependability and performance levels that meet the unique requirements of the internal spacecraft environment. Both JSC Engineering and Mission Operations Directorates are involved in this project.

OIT is the primary system for performing payload operations - the major function of Station. In addition, OIT is the host for crew support applications such as scheduling, mapping, e-mail and communications, information access and vehicle diagnostic support. Given the crew resource constraint of only three people, leveraging their capabilities with good computer tools that have high dependability will ensure more of Station's potential as a unique science laboratory can be realized. The OIT also spans an international set of clients, connecting to modules of the ISS from different countries. Security is a major concern, particularly for a system that might eventually support remote telescience where ground-based science investigators interactively control and monitor on-board experiments.

The results from the OIT HDCP testbed could potentially impact the entire class of NASA on-orbit human space operations support IT systems anticipated for current and next-generation vehicles. Additionally, there is a significant possibility that the HDCP solutions provided for operations support might be applicable to general critical flight system needs for future upgrades and new vehicle designs. It is anticipated that results from the OIT HDCP testbed will generate insights into how to address the design and management of such critical systems, another pressing NASA need.

The Station OIT is a specific implementation of a general "operations support" data system. Traditionally, these operations systems have been extensions of the critical flight control avionics, but in the last ten years, commercial computing and network technology has been replacing these custom systems on both Shuttle and Station. While still requiring coordination with critical systems, these support systems require much higher performance levels, broad compatibility with commercial software development practices and much more sophisticated user applications. Therefore, it is anticipated that certain OIT solutions will be used aboard Shuttle within a year or two of its deployment aboard Station. Furthermore, next generation spacecraft have similar needs for mission operations support, resulting in further development and deployment of these IT systems. For example, 2^nd and 3^rd generation space launch vehicles, Mars transit and habitation spacecraft and even multi-vehicle planetary exploration missions are potential candidates for this dependable network-based information and computing infrastructure. Furthermore, there is a broad class of ground-based support functions also requiring dependable enterprise-class data systems for mission control, science and payload support and even air traffic control.

1. HDCP Testbed

This HDCP testbed will be a rough analogue of the evolving ISS LAN with representative servers/clients. It will consist of several server computers and network components with a range of client-side computers. The testbed will provide hardware and software infrastructure suitable for running software and networking dependability experiments. This infrastructure will be accessible from both NASA Ames Research Park and remotely through the internet.

Dependability attributes whose investigations might be supported on this testbed include:

• Failure tolerance

• Isolation of propagating failure modes

• Elimination of common-mode failures

• Ease of system resource/redundancy management (transparent reconfiguration)

• Computational and data communication reliability and error tolerance

• Sustaining minimum performance levels

• Measurable confidence of the successful propagation of high priority (i.e. critical) packets in a medium of lower priority packets

• Measurement of risk and changes in risk as a function of system software configuration changes

• Security

This testbed is of interest to researchers primarily for the challenges of providing dependable computing and data service using a distributed network of commercial and custom components in the on-orbit domain subject to component failures. Research in architecture, network protocols, failure tolerance and isolation, and software verification are highly relevant. Radiation-induced failures, of significant concern for spacecraft computing, will be modeled as random errors in computation and data communications.

.

Special Notice

Overview

Since 1995 NASA is flying an increasing number of robotic deep space-missions with increasing reliance on software to perform mission functions. Architectures that support software reuse and component-based approaches to developing embedded mission software will be needed. This testbed will be an analogue to NASA flight software; and will enable experimentation with dependability issues in new and existing approaches to flight and ground software. It is expected that the testbed will draw artifacts for experimentation from JPL's Mission Data Systems project, and perhaps other mission software.

Mission Data System (MDS) is an end-to-end platform for improving the dependability of state-based mission software built from component frameworks, principally for robotic deep-space missions. MDS is both a systems engineering process and matching software architecture for developing unified flight, ground & test systems that enable missions requiring reliable, fault-tolerant, autonomous software systems. Adapting projects use the MDS analysis process and underlying frameworks to build mission software. MDS is being developed as a product line to provide a technology core for the next generation of deep-space mission customers. The Mars Smart Lander (MSL) Mission has baselined MDS. Although the process and architecture are shaped by the realities of unmanned space science missions, the concepts apply equally to applications requiring autonomous distributed monitoring and control of physical systems.

The MDS software architecture is expressed as design patterns that can be implemented in any programming language. Current MDS development efforts at JPL are focused on a C++ implementation. The MDS HDCP testbed will likely include a port to Real-time Java¹, through an industrial partnership. This section outlines the MDS products and the benefits they offer to NASA.

MDS Products

Technology Core

MDS provides reusable software building blocks and tools. This framework software consists of over 35 packages for common functionality such as event logging, time services, data management, visualization, units of measurement, state variables, components, connectors, and many more. Each package is tested and documented. The entire set is organized into a layered physical architecture.

Spacecraft Design Process

MDS provides a collaborative engineering tool for systems engineers to capture requirements in terms of familiar concepts: states, commands, measurements, estimators, controllers, and hardware devices. The SDS tool (State Database Server) is a web server that allows systems engineers to collaborate simply using a desktop web browser. Requirements are captured in a state analysis database that can be checked for validity and completeness. The resulting requirements map directly into software elements of the technology core, eliminating errors of translation and reducing cycle time.

Tools for Simpler Operations

In MDS operators specify mission activities in terms of what rather than how, namely, in terms of goal networks rather than command sequences. A goal is simply a constraint on the value of a state variable over a time interval, and a goal network prescribes timing and parent-child dependencies among goals. Both are scripted in "GEL", the Goal Elaboration Language, providing a clear expression of operational intent. Goal-driven operation provides a level of control that is variable between purely time-scripted and fully autonomous, allowing a smooth transition to the more challenging autonomous missions.

Cost Estimation Model

MDS defines a model that estimates customer adaptation costs through objective metrics captured by previous adaptation efforts. These metrics are recorded automatically by a workflow management tool as work packages flow through different phases of requirements, design, development and testing. As missions build adaptations, the estimation model will benefit from additional data, improving a customer's ability to deliver on time and in budget.

Benefits

MDS was developed to address the development and operational needs of the next generation of mission systems. This section briefly surveys those benefits.

Mission System Development And Testing

Until recently, JPL missions were one-of-a-kind, spaced many years apart. Each mission team developed flight software independently. No provisions for reuse were made a priori. Now we are in a new era of frequent launches. Low-cost missions cannot afford to start from scratch. System verification and validation must be both efficient and effective. The solution must provide a pre-integrated, pre-tested reusable technology core.

To satisfy these requirements, MDS has implemented tools and process that provides the following:

• Complex interactions understood at mission, system and component levels

• State decomposition facilitates tracking of system scalability

• Domain knowledge expressed explicitly as models

• Component architecture facilitates measures of responsiveness

• Architecture requires state be determined honestly from the evidence

• Architecture provides a mechanism for identifying the range and impact of faults

• Architecture authorizes and monitors all resource usage

• Uniform architecture facilitates cost tracking associated with system complexity and system reconfiguration.

• Cost models based on objective development data facilitate estimation of fault-related development.

Safer Software

MDS provides a component modeling tool that software engineers use to specify components and connections. Component-based software design elevates software interfaces and interactions to first-class design elements, eliminating 'invisible' interactions that cause hard-to-find problems in large software systems.

A runtime component manager enforces architectural rules, enabling early detection of design defects. Further, a component approach facilitates the use of powerful verification techniques for detecting synchronization errors that cause deadlocks and race conditions.

Verification By Design

In general, many aspects of MDS aim to reduce sources of human error in design, development and test. Here are a few ways that MDS simplifies system verification:

• Goals specify explicit constraints on state and time that are continually monitored, so deviations from expected behavior are immediately reported.

• Errors in units of measurement are eliminated through the SI units package.

• 'Smart pointers' eliminate problems of memory leaks and dangling pointers.

• The component manager enforces architectural rules about legal connections.

• The initialization/finalization package reports circular dependencies and improperly held resources.

• The unified state architecture supports direct comparison between simulated state and estimated state.

• The separation of models from reusable algorithms makes validation of mission-specific items much simpler.

Mission Operations

In the past, missions have been designed for human control from Earth. Flight software has used relatively simple time-based sequencing for commanding. Except for fault protection and a few "critical sequences", spacecraft required ground intervention for unplanned events.

New missions, in contrast, depend on more in situ operations in uncertain environments and, with longer round-trip light-time delays, have less frequent opportunities for communication with Earth. These realities demand more onboard decision-making. The solution must enable selective delegation of control from ground to flight.

To satisfy these requirements, MDS has implemented tools and process that provide the following:

• Operations based on what (constraints on state) rather than how (command sequences)

• Operations can migrate capability and responsibility from ground to flight system to simplify operations and reduce communication needs

• Models express key functional relations among system states, command effects, and observed measurements

• Disciplined architecture provides uniform fault-metric mechanisms

• Fault sources are explicitly captured in goal-failure trees

• Fault response is explicitly modeled as goal elaborations

• Uniform data collection mechanism facilitates run-time monitoring and metrics associated with adaptivity and diagnosability

.

HDCP Testbed

This HDCP testbed, like an actual Mission Project, is expected to include an adaptation of MDS. This testbed could be used to address a wide range of dependability questions. MDS provides a well-disciplined architecture and system engineering approaches that facilitates experimentation with formal verification methodologies. MDS also provides tools to build reliable complex real-time control systems, thereby facilitating experimentation with real-time systems. Experimentation with improved software development methodologies for improved quality and defect reduction could be supported.

It is likely that a significant portion of MDS will be ported from C++ to Real Time Java for the HDCP testbed. Currently, C++ is the language of choice for most OO implementations of mission critical software. However, C++ is an extremely complex programming language. Java addresses some of the complexities of C++, and studies indicate an increase in programmer productivity and decrease in error rate. Java incorporates many features of modern programming language theory, providing an abstraction from details such as memory allocation. For this reason, it also raises issues for embedded, real-time mission systems; issues including real-time capabilities and performance. With the development of the RTSJ, Java now includes technology needed to develop embedded, real-time mission systems. JPL engineers performed an evaluation of Java, and determined that with proper risk management Java could be a suitable implementation language for a mission system. Much research remains to be done to determine the trade-offs for different dependability attributes related to programming language features for real-time embedded systems, and technologies to increase dependability.

The MDS testbed could be used for a wide variety of dependability experiments, as well as studies of the impact of different technologies or methodologies on dependability. Examples of categories of dependability attributes and possible measurements that might be supported are described below, under the broad headings of build/test categories, runtime categories, and operation time categories. Where applicable, it is indicated how the MDS technical approach potentially impacts a dependability category. This might provide a starting point for a hypothesis for a dependability investigation.

Researchers are not limited to these dependability categories nor to the hypothesis suggested by the MDS technical approach. However, researchers should indicate how they could make use of the testbed artifacts to support their dependability experiments.

Build/Test dependability categories address concerns associated with system definition, project management, implementation or verification.

Runtime dependability categories describe how well the system runs.

Operation Time dependability categories that describe how easy the system is to operate correctly.