SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
This paper will discuss approaches to address the need for software maintenance, avoiding the pitfalls of obsolescence, and the use of industry standards by applying institutional maintenance to mission systems.
Explore the source record for details and available documents.
The design complexity of a software system may be characterized within a refinement level (e.g., data flow among modules), or between refinement levels (e.g., traceability between the specification and the design). We analyzed an existing set of data from NASA's Software Engineering Laboratory to test whether changing software modules with high design complexity requires more personnel effort than changing modules with low design complexity. By analyzing variables singly, we identified strong correlations between software design complexity and change effort for error corrections performed during the maintenance phase. By analyzing variables in combination, we found patterns which identify modules in which error corrections were costly to perform during the acceptance test phase.
This viewgraph presentation discusses the maintenance of flight software (FSW) on-orbit and the design of that software to allow maintenance of programs while they are on orbit.
No abstract available
The goal of the Formalized Software Development (FSD) project was to demonstrate improvements productivity of software development and maintenance through the use of a new software lifecycle paradigm. The paradigm calls for the mechanical, but human-guided, derivation of software implementations from formal specifications of the desired software behavior. It relies on altering a system's specification and rederiving its implementation as the standard technology for software maintenance. A system definition for this paradigm is composed of a behavioral specification together with a body of annotations that control the derivation of executable code from the specification. Annotations generally achieve the selection of certain data representations and/or algorithms that are consistent with, but not mandated by, the behavioral specification. In doing this, they may yield systems which exhibit only certain behaviors among multiple alternatives permitted by the behavioral specification. The FSD project proposed to construct a testbed in which to explore the realization of this new paradigm. The testbed was to provide operational support environment for software design, implementation, and maintenance. The testbed was proposed to provide highly automated support for individual programmers ('programming in the small'), but not to address the additional needs of programming teams ('programming in the large'). The testbed proposed to focus on supporting rapid construction and evolution of useful prototypes of software systems, as opposed to focusing on the problems of achieving production quality performance of systems.
NASA’s Deep Space Network (DSN) recently underwent a paradigm shift in its operations approach called Follow the Sun Operations (FtSO) in an effort to increase efficiency for forthcoming expansion of the network. This change requires each Deep Space Communications Complex (DSCC) to remotely control the other two complexes’ antennas during their local day shift, in contrast to locally controlling only their own antennas 24x7. Remote operations increases the workload of each complex during their day shift, specifically that of the Link Control Operators (LCOs), and presents a new challenge for planning and managing the distribution of responsibility for each link. A new DSN software assembly, the Link Complexity and Maintenance (LCM) software, was developed to support workload management for LCOs, as well as for planning site-local maintenance activities. The LCM deployment was a vital part of the transition to FtSO in November 2017. This paper discusses the architecture of LCM, its feature set, and lessons learned during its development and rollout.
The purpose of the Lunar Atmosphere Dust Environment Explorer (LADEE) mission was to measure the density, composition and time variability of the lunar dust environment. The successful mission launched Sept 7, 2013 and was de-orbited and impacted the moon's surface on April 17, 2014. The spacecraft had 3 primary science instruments, the Lunar Dust Experiment, Neutral Mass Spectrometer, and the Ultra Violet Spectrometer. The mission also had a Laser Communications payload that set a record download rate of 622 Mbps (megabits per second) from the moon orbit. The goal is to use the LADEE software base for upcoming smallsat missions. The onboard flight software for the mission was developed using a Model-Based Software methodology and agile software development practices. High level models were developed in Simulink, autocoded to C and layered on Core Flight Executive and Core Flight Software, VxWorks and required board support packages. Software package versions were frozen several years ago, and need to be brought to modern standards for future spacecraft missions. We are evaluating alternate Real Time Operating Systems and avionics architectures that comply with CubeSat form-factor and power limitations. In addition, the tool chain for the software development process has been improved. We will discuss the rationale, trades and implementation for the upgrade path after the LADEE mission.
The Software Engineering Laboratory (SEL) Data Base Maintenance System (DBAM) is explained. The various software facilities of the SEL, DBAM operating procedures, and DBAM system information are described. The relationships among DBAM components (baseline diagrams), component descriptions, overlay descriptions, indirect command file listings, file definitions, and sample data collection forms are provided.
This document is a guidebook to collecting software engineering data on software development and maintenance efforts, as practiced in the Software Engineering Laboratory (SEL). It supersedes the document entitled Data Collection Procedures for the Rehosted SEL Database, number SEL-87-008 in the SEL series, which was published in October 1987. It presents procedures to be followed on software development and maintenance projects in the Flight Dynamics Division (FDD) of Goddard Space Flight Center (GSFC) for collecting data in support of SEL software engineering research activities. These procedures include detailed instructions for the completion and submission of SEL data collection forms.
CNES(F) is responsible for the development of a new generation of Operational Control Center (CMP) which will operate the new heliosynchronous remote sensing satellite (SPOT4). This Operational Control Center takes large benefit from the experience of the first generation of control center and from the recent advances in computer technology and standards. The CMP is designed for operating two satellites all the same time with a reduced pool of controllers. The architecture of this CMP is simple, robust, and flexible, since it is based on powerful distributed workstations interconnected through an Ethernet LAN. The application software uses modern and formal software engineering methods, in order to improve quality and reliability, and facilitate maintenance. This software is table driven so it can be easily adapted to other operational needs. Operation tasks are automated to the maximum extent, so that it could be possible to operate the CMP automatically with very limited human interference for supervision and decision making. This paper provides an overview of the SPOTS mission and associated ground segment. It also details the CMP, its functions, and its software and hardware architecture.
This report introduces a technique of software documentation called conjunctive programming and discusses its role in the development and maintenance of software systems. The report also describes the conjoin tool, an adjunct to assist practitioners. Aimed at supporting software reuse while conforming with conventional development practices, conjunctive programming is defined as the extraction, integration, and embellishment of pertinent information obtained directly from an existing database of software artifacts, such as specifications, source code, configuration data, link-edit scripts, utility files, and other relevant information, into a product that achieves desired levels of detail, content, and production quality. Conjunctive programs typically include automatically generated tables of contents, indexes, cross references, bibliographic citations, tables, and figures (including graphics and illustrations). This report presents an example of conjunctive programming by documenting the use and implementation of the conjoin program.
The application of assurance engineering techniques improves the duration of failure-free performance of software. The totality of features and characteristics of a software product are what determine its ability to satisfy customer needs. Software in safety-critical systems is very important to NASA. We follow the System Safety Working Groups definition for system safety software as: 'The optimization of system safety in the design, development, use and maintenance of software and its integration with safety-critical systems in an operational environment. 'If it is not safe, say so' has become our motto. This paper goes over methods that have been used by NASA to make software design improvements by focusing on software quality and the design and inspection process.
This paper is predominantly a nontechnical discussion of some significant aspects of the initial flight qualification and operational maintenance of the flight control system software for the X-29A technology demonstrator. Flight qualification and maintenance of complex, embedded flight control system software poses unique problems. The X-29A technology demonstrator aircraft has a digital flight control system which incorporates functions generally considered too complex for analog systems. Organizational responsibilities, software assurance issues, tools, and facilities are discussed.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
A microcomputer interactive data system (MINDS) software package for the 8086 family of microcomputers is described. To enhance program understandability and ease of code maintenance, the software is written in PL/M-86, Intel Corporation's high-level system implementation language. The MINDS software is intended to run in residence with real-time digital control software to provide displays of steady-state and transient data. In addition, the MINDS package provides classic monitor capabilities along with extended provisions for debugging an executing control system. The software uses the CP/M-86 operating system developed by Digital Research, Inc., to provide program load capabilities along with a uniform file structure for data and table storage. Finally, a library of input and output subroutines to be used with consoles equipped with PL/M-86 and assembly language is described.
A discussion is presented of some significant aspects of the initial flight qualification and operational maintenance of the flight control system softward for the X-29A technology demonstrator. Flight qualification and maintenance of complex, embedded flight control system software poses unique problems. The X-29A technology demonstrator aircraft has a digital flight control system which incorporates functions generally considered too complex for analog systems. Organizational responsibilities, software assurance issues, tools, and facilities are discussed.