Infusing Next-Generation Fault Management Software on...

Solar Probe Plus A NASA Mission to Touch the Sun

Infusing Next-Generation

Fault Management Software on Solar Probe

Plus Justin Thomas Russell Turner

2012 Spacecraft Flight Software Workshop

Nov. 7 - 9, 2012

*This presentation does not contain US Export controlled information*


Infusing Next-Generation Fault Management Software on Solar Probe Plus FSW 2012

Outline

Solar Probe Plus and the Autonomy Challenge

ExecSpec Technology Case and Overview

Technology Readiness

Solar Probe Plus Infusion

2



Solar Probe Plus (SPP) Mission

In-situ measurements of the solar wind within the corona to: Determine the structure and dynamics of the Sun’s coronal

magnetic field Understand how the solar corona and wind are heated and

accelerated Determine what mechanisms accelerate and transport energetic

particles 31 institutions, 106 scientists 2018 launch on Atlas V (with upper stage) ~7 year mission duration Venus gravity assist flybys Closest approach – 9.5 Sun radii Orbit period – 88-150 days 11 day encounter (prime science) period

3



SPP Spacecraft

Carbon-carbon heat shield (TPS) 2,000 °C at closest approach

An array of heliophysics instruments Actively-cooled, steerable solar array wings Blowdown monoprop propulsion Wheel-based 3 axis-stabilized ACS 3 processor redundant avionics Spacewire avionics bus HGA, TWTA, Ka-band downlink Single fault tolerant

4



SPP Autonomy Challenges

Ground communication outages of up to 34 days due to TPS blockage and orbit geometry

Two major driving fault cases for on-board Fault Protection

potentially requiring correction within seconds Maintaining TPS pointing Avoiding solar array overheating

Due to the above, Autonomy must be capable of recovering into an

operational state during thermal-critical regions (in and around encounter)

Autonomy solution must effectively manage design complexity, execute predictably and robustly, and provide high levels of verifiability

5



2008 NASA Fault Management Workshop Findings

Finding #1 – Avoid the downstream testing crunch “Unexpected cost and schedule growth during final system integration and test are a result of underestimated Verification and Validation (V&V) complexity combined with late resource availability and staffing”

Finding #4 – Identify FM representation techniques and FM design guidelines

“There is insufficient formality in the documentation of FM designs and architectures, as well as a lack of principles to guide the processes. Recommendation: Identify representation techniques to improve the design, implementation and review of FM systems.“

6



APL Heritage Autonomy – Rule-Based

7



APL ExecSpec Autonomy – Model-Based

8



Why ExecSpec? Understandability Understandability defines the ability to design, display and review the autonomy system such that non-

software domain experts or system engineers can understand the design. Necessary for reviews: FM is multi-disciplinary and need all subsystems understanding the ConOps

to produce good designs Essential for managing complexity and easing future modifications: Better context is key to making

the right change and translating need into implementation ExecSpec is based on a visual state-transition diagram representation that provides improved system context to ease interpretation

Verifiability Verifiability defines the ability to exhaustively and rapidly verify the autonomy system. Prevent crunch in I&T testing: Provides early on testing Ensure risk level: Current testing may not find or see all problems

ExecSpec provides a desktop-based test environment and sophisticated model checking capability to enable early and thorough testing Modifiability Diagrams are executed directly by an interpreter rather than compiled Can be easily modified during flight

9



ExecSpec Background

Developed under several consecutive APL IRADs (FY06 – FY08) – George Cancro PI Based on predictable, robust finite state machines

(FSMs) Design tool (ESD) provides intuitive visual

programming for state model logic through diagrams

Diagrams executed directly using on-board interpreter (ESI) rather than code-generated Monitoring tool (ESV) provides situational

awareness through animation of diagrams Provides early testing capability during design-

time on the desktop (user-driven or user-scripted simulation using flight interpreter)

Formal verification facility generates NuSMV compatible model for model checking

10



ExecSpec Interpreter Schematic Diagram

State Machine

Interpreter

Input Interface

Output Interface

FSM Definition

Output Definition

Input Definition

Input List Output List

Flight Software

Input Events

Output Commands

Feedback Events



ExecSpec Overview

12

Embedded System

Visual Development & Test Environment (ESD) Diagrams

Telemetry to animate Functionality during

Operations

ENG

INE

Real-Time Embedded Interpreter (ESI)

µP

Data from Vehicle

Decisions (Domain-Specific

Commands)



ExecSpec - ESD User Interface Overview

Timeline

Diagram View

Input Variable

View

Time Slider Playback Toolbar

Status Bar

Simulation Toolbar

Drawing Toolbar

Attribute View

Time Rule LOD Toolbar

Output View

Property View

Input Variables

Time History Tiers

Current State

Outline View

Search Tool Drilldown View



ExecSpec Monitoring

14



Formal Verification with Model Checking – Approach

15

Requirement: Safety: “Never radiate while swapping antennas”

AG !(twta=radiating & ant=swapping)

Counter Example

Requirements

Autonomy Design

(ExecSpec)

Common Checks

Logic Specification

Model Checker (NuSMV)

Counterexamples



Formal Verification with Model Checking – 2012 Status

Completed ExecSpec to NuSMV model translator Successfully translated

full STEREO model

Proved a critical safety constraint within 15 seconds on a laptop

Assumptions Plant

Models

Interactions across significant portions of the system

16



ExecSpec Technology Readiness

Current Spaceflight Technology Readiness Level (TRL) = 5 - 5.5 Activities

2008 – NASA STEREO Mission Demonstration (Simulation)

2012 – UAV Flight Tests

17



NASA STEREO Mission Demonstration – 2008

STEREO Autonomy system translated into an ExecSpec model (43

diagrams)

ExecSpec flight interpreter inserted into STEREO flight software (replacing APL rule-macro system)

ExecSpec ground system integrated into STEREO ground system

STEREO ExecSpec system run on a engineering model (EM) hardware testbed from the NASA STEREO program exercising most but not all of the original STEREO fault management autonomy requirements.

18



UAV Flight Tests – 2012

Objective: Demonstrate ExecSpec technology readiness by autonomously performing critical in-flight fault management in an unforgiving environment (on-board an Unmanned Aerial Vehicle (UAV) platform)

19

PRIMARY OBJECTIVE Proserus Unicorn UAV

STRETCH OBJECTIVE Deployed Combat UAV



UAV Flight Tests – Technical Approach

Establish fault scenario(s) and demo CONOPS

Develop fault management design (Autonomy model and ExecSpec integration approach)

Integrate into the UAV system via the APL Autonomy Toolkit (ATK) ExecSpec flight engine (ESI) ExecSpec ground monitoring (ESD)

Perform testing (simulation-based, HWIL, flight) Perform final field tests

20



UAV Flight Tests – Excessive Bank Angle Fault

1. ExecSpec detects a bank angle violation (> a fixed threshold) using on-board bank angle

2. ExecSpec overrides nominal navigator and levels out the aircraft using a basic dampened response over a few seconds (rather than commanding a large instantaneous change in roll angle)

3. ExecSpec continues to level out the aircraft until the bank angle is considered safe (< a fixed threshold)

4. ExecSpec relinquishes control back to nominal navigator

21



UAV Flight Tests – Final Field Tests

Unicorn UAV Field Tests May 2012 Location: Maryland Several hours of flight time resulting in over 10 successful fault

corrections

Deployed Combat UAV Field Tests June 2012 Location: U.S. West Coast Approximately 30 minutes of flight time with several successful

fault corrections

Flight Visualization Video

22



SPP Infusion

SPP Phase B Autonomy Trade Study ending Oct 31st, 2013

Demonstrate ExecSpec feasibility for SPP

Primary concerns to address:

1. Scalability to a SPP-like (complex) spacecraft

2. Fit within allocated on-board resources (CPU, RAM, NVM)

3. Full CONOPS (in-flight updates, override, low-bandwidth/emergency mode)

23



SPP Infusion – MESSENGER Demonstration

Leverage APL’s infrastructure with the NASA MESSENGER mission

Port the MESSENGER FPP Autonomy system to ExecSpec

Inject ExecSpec flight and ground segments into the MESSENGER Testbed for high-fidelity, closed-loop simulations

Execute Fault Protection test suite and demonstrate CONOPS

24

SPP Ground System MESSENGER Testbed SPP Avionics μP

ESD InControl ESI FPP UDP UDP



SPP Infusion – FPP Autonomy Bypass

FPP has ample available resources to allow integration without affecting system timing

Enables demonstration using SPP baseline flight processor (LEON3FT), FSW architecture (cFE), and ground system (L3 InControl)

25

MESSENGER FPP

Existing Autonomy

On-Board Telemetry

Command Sequences

SPP Avionics

ExecSpec (ESI)

UDP

UDP



Questions?

Thank You

Acknowledgements:

NASA, JHU/APL, Bill Van Besien, George Cancro, Jonathan Castelli, Bob Chalmers, Bill Fitzpatrick, Adrian Hill, Eli Kahn, Michael Lucks, Chris Olson, Michael Pekala, David Scheidt, Adam Watkins

26

Date post:	05-Jun-2018
Category:	Documents
Upload:	trannguyet
View:	214 times
Download:	0 times

Infusing Next-Generation Fault Management Software on...

Documents