Developing Lunar Flashlight and Near-Earth Asteroid Scout Flight Software Concurrently using Open-Source F Prime Flight Software Framework

NASA’s Lunar Flashlight (LF) and Near-Earth Asteroid (NEA) Scout CubeSat missions are planned to launch in 2022. Lunar Flashlight is a low-cost secondary payload concept that will map the lunar South Pole for volatiles and demonstrate several technological firsts, including the first planetary CubeSat mission to use green propulsion, and the first mission to use lasers to look for water ice. NEA Scout is a low-cost concept that will map an asteroid and demonstrate several technological firsts, including being the first CubeSat to reach an asteroid. Flight software for both CubeSat missions is based on the open-source F Prime Flight Software Product Line developed by JPL. F Prime utilizes a reusable component-based architecture with typed ports that can be interconnected to form a topology. Also, F Prime includes a set of auto-coding tools used to generate components and topologies that can be deployed for various mission specific applications. Both CubeSats share a common set of avionics for command and data handling (C&DH), telecom and power. This commonality in hardware is translated to a shared deployment in software enabling concurrent flight software development for both CubeSats. The modularity and reusability in F Prime enable such concurrent flight software development for different applications given a common set of avionics. In particular, F Prime has been used successfully to develop a common software deployment for the Sphinx C&DH platform used on both CubeSats. The common F Prime deployment for Sphinx has also been made open source to provide a starting point for any future F Prime software deployments utilizing the Sphinx platform. This paper provides a comparison between the Lunar Flashlight and NEA Scout Flight Software deployments highlighting the use of a common shared set of F Prime components developed for the Sphinx platform along with general lessons learned for CubeSat flight software development with the F Prime Framework

Assurance Benefits of ISO 26262 compliant Microcontrollers for safety-critical Avionics

The usage of complex Microcontroller Units (MCUs) in avionic systems constitutes a challenge in assuring their safety. They are not developed according to the development requirements accepted by the aerospace industry. These Commercial off-the-shelf (COTS) hardware components usually target other domains like the telecommunication branch. In the last years MCUs developed in compliance to the ISO 26262 have been released on the market for safety-related automotive applications. The avionic assurance process could profit from these safety MCUs. In this paper we present evaluation results based on the current assurance practice that demonstrates expected assurance activities benefit from ISO 26262 compliant MCUs.Comment: Submitted to SafeComp 2018: http://www.es.mdh.se/safecomp2018

Towards a methodology for rigorous development of generic requirements patterns

We present work in progress on a methodology for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. We consider the failure detection and management function for engine control systems as an application domain where product line engineering is useful. The methodology produces a generic requirement set in our, UML based, formal notation, UML-B. The formal verification both of the generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools

Towards a method for rigorous development of generic requirements patterns

We present work in progress on a method for the engineering, validation and verification of generic requirements using domain engineering and formal methods. The need to develop a generic requirement set for subsequent system instantiation is complicated by the addition of the high levels of verification demanded by safety-critical domains such as avionics. Our chosen application domain is the failure detection and management function for engine control systems: here generic requirements drive a software product line of target systems. A pilot formal specification and design exercise is undertaken on a small (twosensor) system element. This exercise has a number of aims: to support the domain analysis, to gain a view of appropriate design abstractions, for a B novice to gain experience in the B method and tools, and to evaluate the usability and utility of that method.We also present a prototype method for the production and verification of a generic requirement set in our UML-based formal notation, UML-B, and tooling developed in support. The formal verification both of the structural generic requirement set, and of a particular application, is achieved via translation to the formal specification language, B, using our U2B and ProB tools

The repository-based software engineering program: Redefining AdaNET as a mainstream NASA source

The Repository-based Software Engineering Program (RBSE) is described to inform and update senior NASA managers about the program. Background and historical perspective on software reuse and RBSE for NASA managers who may not be familiar with these topics are provided. The paper draws upon and updates information from the RBSE Concept Document, baselined by NASA Headquarters, Johnson Space Center, and the University of Houston - Clear Lake in April 1992. Several of NASA's software problems and what RBSE is now doing to address those problems are described. Also, next steps to be taken to derive greater benefit from this Congressionally-mandated program are provided. The section on next steps describes the need to work closely with other NASA software quality, technology transfer, and reuse activities and focuses on goals and objectives relative to this need. RBSE's role within NASA is addressed; however, there is also the potential for systematic transfer of technology outside of NASA in later stages of the RBSE program. This technology transfer is discussed briefly

Supporting the automated generation of modular product line safety cases

Abstract The effective reuse of design assets in safety-critical Software Product Lines (SPL) would require the reuse of safety analyses of those assets in the variant contexts of certification of products derived from the SPL. This in turn requires the traceability of SPL variation across design, including variation in safety analysis and safety cases. In this paper, we propose a method and tool to support the automatic generation of modular SPL safety case architectures from the information provided by SPL feature modeling and model-based safety analysis. The Goal Structuring Notation (GSN) safety case modeling notation and its modular extensions supported by the D-Case Editor were used to implement the method in an automated tool support. The tool was used to generate a modular safety case for an automotive Hybrid Braking System SPL

AFTI/F-16 digital flight control system experience

The Advanced Flighter Technology Integration (AFTI) F-16 program is investigating the integration of emerging technologies into an advanced fighter aircraft. The three major technologies involved are the triplex digital flight control system; decoupled aircraft flight control; and integration of avionics, pilot displays, and flight control. In addition to investigating improvements in fighter performance, the AFTI/F-16 program provides a look at generic problems facing highly integrated, flight-crucial digital controls. An overview of the AFTI/F-16 systems is followed by a summary of flight test experience and recommendations

Predicting Cost/Reliability/Maintainability of Advanced General Aviation Avionics Equipment

A methodology is provided for assisting NASA in estimating the cost, reliability, and maintenance (CRM) requirements for general avionics equipment operating in the 1980's. Practical problems of predicting these factors are examined. The usefulness and short comings of different approaches for modeling coast and reliability estimates are discussed together with special problems caused by the lack of historical data on the cost of maintaining general aviation avionics. Suggestions are offered on how NASA might proceed in assessing cost reliability CRM implications in the absence of reliable generalized predictive models

Preliminary candidate advanced avionics system for general aviation

An integrated avionics system design was carried out to the level which indicates subsystem function, and the methods of overall system integration. Sufficient detail was included to allow identification of possible system component technologies, and to perform reliability, modularity, maintainability, cost, and risk analysis upon the system design. Retrofit to older aircraft, availability of this system to the single engine two place aircraft, was considered