0% found this document useful (0 votes)
75 views3 pages

Assignment 2: Software Verification and Validation

This document discusses verification and validation (V&V) of autonomy software for spacecraft. It argues that V&V of autonomy software is not inherently more difficult than V&V of traditional spacecraft control software. The key is decomposing the large state space into tractable equivalence classes that can be tested. Autonomy software includes mission planners, executives, fault detection software, science autonomy software, and rover navigation software. Current validation methods for science autonomy software are empirical and ad hoc, but adequate for their deployment context. The document concludes that many challenges in autonomy software V&V also exist for traditional software and can be addressed using similar methods as for traditional spacecraft software V&V.

Uploaded by

Muhammad Irfan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
75 views3 pages

Assignment 2: Software Verification and Validation

This document discusses verification and validation (V&V) of autonomy software for spacecraft. It argues that V&V of autonomy software is not inherently more difficult than V&V of traditional spacecraft control software. The key is decomposing the large state space into tractable equivalence classes that can be tested. Autonomy software includes mission planners, executives, fault detection software, science autonomy software, and rover navigation software. Current validation methods for science autonomy software are empirical and ad hoc, but adequate for their deployment context. The document concludes that many challenges in autonomy software V&V also exist for traditional software and can be addressed using similar methods as for traditional spacecraft software V&V.

Uploaded by

Muhammad Irfan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Assignment 2

Software Verification And Validation

Irfan Muhammad 70067306

Section T
Autonomy Software Verification and Validation
Might Not be as Hard as it Seems

SUMMARY

This problem can be addressed for autonomy software in the same way that it has been addressed for
traditional software: by decomposing the large state space into a tracta- ble number of equivalence classes that
exhibit qualitatively identical behavior, each one containing a large number of states.
The technological concern is that the particular technology used in autonomy software tends to involve
techniques like search that are 1) not used in traditional software and 2) not amenable to exhaustive testing
because the number of possible states is astronomi- cally large.
From this repertv we can identify the following major classes of autonomy software: 0 Mission planners 0
Executives 0 Fault detection, isolation and recovery (FDIR) software 0 Science autonomy software 0 Rover
navigation software, which can be further broken down into: o Terrain analysis and modeling o Localization o
Path generation I will now dis- cuss each of these in terms of the kinds of V&V strategies that could be
applied.
The key to making autonomy software reliably testable therefore is exactly the same as that for making any
non-trivial software reliably testable: design the software in such a way that its structure allows its state space
to be decomposed into a tractable number of equivalence classes with respect to a property of interest, and then
perform tests on a small number of samples from each equivalence class.
A survey of spacecraft autonomy software The first (and as of this writing still the only) autonomous
spacecraft was STl (originally DSI) which operated autonomously for two days under the control of the
Remote Agent Experiment (RAX) [Pe1198a].
The purpose of this paper is to try to alleviate some of that concern by arguing that veri- fying and validating
autonomy software is not different in any fundamental way fiom verifying so-called “classical” spacecraft
control software.
The Mars Science Laboratory (MSL) mission, currently in pre-phase-A planning, is also considering the use of
autonomy software, including autonomous science software for automatically classifying images and spectra
into scientifically interesting categories.
Summary and Conclusions I have presented some informal arguments that verifying and validating autonomy
software is not inherently any more difficult than verifying and validating traditional spacecraft control
software.
I will adopt a purely operational definition: autonomy software is any software that fits into a part of the
spacecraft control process that would normally involve a human.
Autonomous FDIR software (e.g. [Williams96]) typically works by taking a model of the spacecraft and
running it “backwards”, that is, by taking the raw measurements from sensor data and the commands sent to
the hardware and finding the most likely state of the given model that explains the observed measurements.
Current validation methods for science autonomy software are purely empirical and mostly ad hoc, which is
adequate for the context in which these algorithms are likely to be deployed.
Thus, all software must be tested by dividing the possible states of the software into a small number of
equivalence classes and testing sample states fkom within each class.
The impetus for using autonomy software in the first place is to reduce ground opera- tions costs and enable
new classes of missions that would not be otherwise possible.
Attitude control and fault protection software are therefore not autonomy software (at least not on unmanned
spacecraft) simply because it is impossible to put a human in those loops.
Many of the perceived hard problems in autonomy software V&V also exist for traditional software, and can
be solved using many of the same methods and techniques used for traditional spacecraft software.

You might also like