Quality attributes for mission flight software: A reference for architects

Wilmot, Jonathan; Fesq, Lorraine; Dvorak, D.

doi:10.1109/aero.2016.7500850

Cited by 8 publications

(11 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Quality attributes (criteria 4) were inspired from Wilmot et al (2016). Not all fourteen quality attributes identified by NASA's Software Architecture Review Board were taken, only those more closely related to software implementation.…”

Section: Reference Mission Software Selection Criteriamentioning

confidence: 99%

A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions

Miranda

Ferreira

Kucinskis

et al. 2019

J.Aerosp. Technol. Manag.

View full text Add to dashboard Cite

Nanosatellite missions are becoming increasingly popular nowadays, especially because of their reduced cost. Therefore, many organizations are entering the space sector due to the paradigm shift caused by nanosatellites. Despite the reduced size of these spacecrafts, their Flight Software (FSW) complexity is not proportional to the satellite volume, thus creating a great barrier for the entrance of new players on the nanosatellite market. On the other side, there are some available frameworks that can provide mature FSW design approaches, implying in considerable reduction in software project timeframe and cost. This paper presents a comparative survey between six relevant flight software frameworks, compared according to commonly required ‘New Space’ criteria, and finally points out the most suitable one to the VCUB1 reference nanosatellite mission.

show abstract

Section: Reference Mission Software Selection Criteriamentioning

confidence: 99%

A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions

Miranda

Ferreira

Kucinskis

et al. 2019

J.Aerosp. Technol. Manag.

View full text Add to dashboard Cite

show abstract

“…While a majority of the heritage analysis focused on FSW functional features a significant and conscious effort was made to address the cFS's architectural quality attributes [3] . Quality attributes are hard to quantitatively trade but they can ultimately determine the success or failure of a software product line.…”

Section: Architectural Highlightsmentioning

confidence: 99%

“…Layer 1 contains the Operating System (OS) and Board Support Package (BSP) and access to the functionality in these components is controlled through two APIs: the Operating System Abstraction Layer (OSAL [3] ) and the Platform Support Package (PSP).…”

Section: Api-basedmentioning

confidence: 99%

“…The APIs in Layers 1 and 2 have been instrumental in the cFS's success across multiple platforms and the cFE API has remained functionally unchanged since the launch of the Lunar Reconnaissance Orbiter in 2009. Together the APIs define an application runtime environment for the applications [3] in Layer 3. The application layer contains thread-based applications as well as libraries (e.g.…”

Section: Api-basedmentioning

confidence: 99%

See 1 more Smart Citation

Increasing flight software reuse with OpenSatKit

McComas

2018

2018 IEEE Aerospace Conference

View full text Add to dashboard Cite

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the core Flight System (cFS) as open source under the National Aeronautics and Space Administration (NASA) Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a lowearth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities with minimal FSW development experience that are building CubeSats. This paper describes the OpenSatKit [2] that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users.OpenSatKit provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes eight cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi.OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

show abstract

“…This same approach of limiting ilities to system level analysis exists in software development. For instance, this approach is taken in [4], which uses non-functional requirements for software architecting. On their approach, each ility is listed in a table that can be used to assess the ability of the architecture to achieve desired system aspects for space mission flight software.…”

Section: Introductionmentioning

confidence: 99%

On Using Ilities of Non-Functional Properties for Subsystems and Components

Lee

Collins

2017

Systems

View full text Add to dashboard Cite

Abstract:The use of ilities for systems engineering of subsystems and components is investigated. Prior work on ilities has emphasized or restricted their application to system level, non-functional properties. The premise of this work is that ilities can be applied with benefit, and in some cases out of necessity, to lower levels of systems as well. The veracity of this premise is established by providing examples that demonstrate how some ilities are passed and used as a non-functional property of electrical and structural subsystems in aircraft. It is further demonstrated that flowing ilities down to the subsystem level is not only a useful practice for systems engineers, it can also be an essential step to ensure that customer needs are actually met by the system under design or service. Systems engineers often lack the detailed knowledge of the subsystems or components required to translate ilities into functional requirements. Thus, the system ilities are passed down and translated from non-functional to functional requirements by subject matter experts. We first discuss the definition, characteristics and scope of ilities. Then, we formulate the application of ilities at a subsystem level. Next, we show aircraft engineering examples for ilities applications. The application process is formalized with diagrams, and ilities' relation to system architecture engineering is discussed. The work concludes with a summary and suggestions for future work.

show abstract

Quality attributes for mission flight software: A reference for architects

Cited by 8 publications

References 2 publications

A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions

A Comparative Survey on Flight Software Frameworks for ‘New Space’ Nanosatellite Missions

Increasing flight software reuse with OpenSatKit

On Using Ilities of Non-Functional Properties for Subsystems and Components

Contact Info

Product

Resources

About