Using Rules-based Statecharts to Automate Satellite Behaviors

Small Satellite Conference 2014

Using Rules-based Statecharts to Automate

Satellite Behaviors

Kenneth Center, PhD

Director of Advanced Software Technologies

PnP Innovations

[email protected]

p2Small Satellite Conference 20148/4/2014 10:55 AM

Outline

• Background (AMM and Aspire)

• Motivation (Role of Rules, Statecharts)

• Technology Leveraged (JPL STAARS)

• New Capability Developed

• Integration with AMM

• Example Use Cases

• Benefits

• Current Status

• Summary & Acknowledgements


Autonomous Mission Manager (AMM)Application of Architecture

High Value Assets

with Hosted

Payloads

Space-Space

Surveillance Earth Observing

Satellites

Taskable

Ground-based

Sensors

Airborne

Sensors

CubeSatsDynamic Joining of

Autonomous

Federated Assets

Ground Tasking &

Processing Sites

Ground Network

Co-Orbital

Visitor

Direct interactions between assets and

autonomous decision-making remove human

operator latency and reduce response times

Enable Space Domain user

community to extract maximum

utility from assets

Operators specify operational rules

in natural language to create/tailor

system behavior to mission needs

Rules stored in

libraries for reuse


Adaptive Scalable Portable Infrastructure

for Responsive Engineering (ASPIRE)

• IP-based middleware supporting space systems

• High-performance messaging on the satellite

• Reliable message exchange with remote

components over the network

• Electronic data sheets define interfaces

• Components can be dynamically added/removed

from system – software adapts to available data

providers

• Control scope of data visibility between Aspire

Domains on same physical network

• Wire-level compatibility on many common

processors and operating systems

• Promotes high or complete software re-use

• Command & Control

• Data Processing

• Automated Operations

Ground Infrastructure (Over Ethernet)

Network

Adapter(s)

Processor

Manager

Data

Directory

Federated Assets

• Cluster Ops

• Distributed

Functionality

• Aspire core component

address management

• Time distribution

Mission

Software

Satellite

Hardware

Aspire

Components

• Data Registrar

• Data Query support

Satellite Flight Systems

S-G

Links

Cross-Links

Network Messaging


Mes

sa

gin

g S

erv

ice

s

Syste

m (

OS

) S

erv

ices

AMM Data Architecture Layers

API

Subsystem Layer Services

APIPointing Power Comm Thermal

Device/Application Support Layer Services

API APIPhysics-

Based I/Fs

Planning

Support

Metadata

Repo

Remote

Files

Misc

Utility

API

Autonomy ServicesAssessment

APIPlanning/

Scheduling

Execution

Rules

Fusion

TacticsTacticsTactics

API

Platform HardwareAtt/Rate Sensors

Power Switching

Radios

ThrustersSensors

SensorsSensors APIAPI

RulesGoals

Response

RulesRulesRules

Data Store

React’n Wheels

GNC

Aspire Middleware

The latest addition…


Using Rules for Decision Logic

• Some high-level decision-making lends itself well to a rules-based

solution

– Say “what to do”, not “how to do it”

– Handle complex problems that are difficult to code in procedural

programming

– More efficient way of mapping rule patterns to domain object data than

procedural programming

• Target “Mission-level” behaviors that utilize resources in a wider

system data architecture

– More natural way for humans to express behaviors….

• We chose Drools as the baseline Rule Engine

– Battle-proven, freely-available enterprise solution

– Performs pattern matching of ‘facts’ to ‘rules’ using modified Rete

algorithm

– Java API


State Machinesto Define Behaviors

• A majority of the AMM mission code modules employ state machine logic

• Even simple state machines with just a few states can have many transition paths

• Implementing state machine logic by hand is tedious, repetitive and takes a lot of

discipline to keep consistent with the design

• Rules are a much better representation language for a state machine that

procedural code (better mapping, less code, faster decision-making)


The JPL STAARS Process

• What is STAARS?

– A JPL home-grown model-based engineering process for software development.

– STAARS (STate-based Architecture and Auto-coding for Real-time Systems)

– Combines 5 tools that can be customized for each project

UML Modeling

State-based

Framework

AutocodingTest Harness

Model

Checking

STAARS was used to specify

autonomous operations for most

phases of the JPL Curiosity mission


STAARS Component Summary

• UML Modeling– Explicitly capture the intent of the requirements– Formally capture the behavior in a model– Create a crisp notion of state

• State-based Framework– Supports the UML standard

– Allows developers to think and work with higher constructs – states, events and transitions

• Auto-coding– Light-weight Java program– Reads in the Model which is stored in a non-

proprietary data format (XML)– Converts the input model into an internal data

structure– Has multiple back-ends to support different project

requirements

• Test harness– Ability to run the model stand-alone – module test

environment

• Model Checking– Automatic generation of Verification models– Exhaustively explore the state-space of the model

– Checks for various correctness properties within the model

JPL Autocoder

C++

C - QF2

C - QF3

C - MSL

Promela/

C

Python

Model.XML

Model.cpp

Model.c

Model.c

Model.c

Model.pml

Model.py

Model.c

Input

Parser

Drools

Drools-Aspire “back-end” added

Model.drl


MagicDraw UML


Statechart Features Supported

a) Top level state machine definition

b) States. No limit on nesting

c) Calls to external functions/services

d) State initial entry point

e) Entry conditions

f) Transition events

g) Exit conditions

h) Logical guard conditions

i) Temporal guard conditions

j) Orthogonal regions

k) Event generation

m) Internal transitions

m’) Self Transition

p) Publication of parameterized messages


JAspire API

JAVA

Aspire Reliable Message Transport Layer

IntelligentAgent Class

Auto-Coded Drools Statechart

Drools

SatelliteTelemetry

Events

SatelliteResources

Planners

Relationship to OtherAMM Capabilities

• Sits atop robust capabilities already developed for AMM

• Statechart behaviors are represented as rules-based patterns

• Drools knowledge base is the source of data on which rules operate

• External data sources are made available through the knowledge base


xTEDS Structure

The standard xTEDS header –

referencing the syntax-

enforcing Schema and citing the

Version of the xTEDS

Interfaces in xTEDS provide a

formal way of encapsulating a

logical collection of messages.

We’ll define standard interfaces

for AMM SOA constructs

The “kind” and “Qualifier”

elements of the xTEDS are the

means of richly expressing “data

points” in the system. We strive

for atomic characterization of

data – then enhance their

context and interpretation with

metadata.

Three message primitives are

supported in ASPIRE –

Notifications (one-way from

provider), Commands (one-way

from consumer), and Service

Requests (command-response pair)


Drools Pattern Generation

rule "BeginForecastCeilingToEvaluatePlanBTransition" salience 10

when

cloudCeilingDataMsg : CloudCeilingDataMsg()

InForecastCeiling()

Ceiling2500ft()

then

retract( cloudCeilingDataMsg );

insert( new InForecastCeilingToEvaluatePlanBTransition() );

logger.info( "BeginForecastCeilingToEvaluatePlanBTransition: complete" );

end

declare RequestWeatherPrediction extends AspireMessage

@Message( interfaceName = "ICourseOfAction",

messageType = Notification,

messageArrival = EVENT,

globalVariableName = "gRequestWeatherPrediction",

role = Provider )

MissionTime : long

@MessageVariable( type = UINT32 )

WeatherType : String

@MessageVariable( type = STRING )

end

global RequestWeatherPrediction gRequestWeatherPrediction

rule "Ceiling2500ft" salience 200

when

CloudCeilingDataMsg( Ceiling < 2500.0 )

then

insertLogical( new Ceiling2500ft() );

logger.debug( "Ceiling2500ft: complete" );

end

AMM

xTEDS

DefinitionsxTEDS Data Sheets define bindings

between message variables and Drools

knowledge base “facts”

Statechart logic results in rules

synthesis to manage state actions and

transitions


Relationship to AMM

STAARS

SDT

bdStudio

BAIT

Define Asset/System

Behaviors/Responses

Ground Segment

Space Segment

Graphical

UML

STAARS

State Sim

Systems Engineers or

Satellite Operators

AutoCode AMM

Architecture

Aspire

Messaging

Drools

SCL

C/C++

Promela

Languages

AMM

xTEDS

Definitions

AMM

SOA

Modules

Validation Cycle

Deploy

System

AspireStudio

• Move toward allowing operators, not programmers, to define system behaviors

• Apply behaviors at multiple levels within the AMM system

– Platform level decisions, responses

– System level assignment of responsibilities and “strategies”


OPERATIONAL PROCESS

Select Statechartfor use on a Mission

Dependency tree selects necessary support services

Create flight software load

Upload to satellite

Execute

Dynamically update statechart during

execution

Select Mission Modules from AMM Library

Start with a statecharttemplate Interactively

specify states & transitions

Map actions and guards to

Aspire Messages &

AMM ServicesAuto-generate

Code

Deploy the statechartin test environment

with selected Mission Modules

Verify proper operation

SPIN-check to verify

correctness

Commit Generated Module to Library

Process Flow

DEVELOPMENT PROCESS


An Example…

• Capture of “checklist-type” decision flow

• Accesses external services to get data conditions at specified times

• Execute a plan if certain threshold criteria are met


Quick Mod…

1. Pick a state from the library

and drop it on the diagram

2. Rewire transitions to use it

3. Generate new code module

4. Deploy, witness new

behaviors immediately


Current Status

• Have demonstrated capabilities for multiple use cases

– Satellite-level decisions (using subsystem controls) based on evaluation of

onboard events and telemetry

– System-level decisions using data from multiple assets, applying tasking

accordingly

• In the process of applying to an FDIR use case

– Compare ‘modeled’ subsystem statechart to ‘measured’ statechart

– Identify departures from nominal conditions

– Follow state-described procedures to diagnose, resolve

• Have transitioned to execution on lightweight embedded processors

– BeagleBone Black, running Denx Linux + JRE

– Evaluating performance, minimizing code footprint


Summary

• More efficient capture of system behaviors that can be

accomplished by non-programmers

– Systems Engineers

– System Operators

• Graphical representations and generated code always stay

in sync – no programmer’s development and test time is

required

• Ability to dynamically update behaviors of a deployed

system by modifying the statecharts

• Generating Promela representation allows SPIN

verification to be conducted for more automated and

complete test coverage


Acknowledgements

• Thanks to Paul Zetocha, Section Chief of the

AFRL/RVSVC Space Vehicles Directorate at the Air Force

Research Laboratory, Kirtland Air Force Base,

Albuquerque, New Mexico, for sponsoring this research

• Many thanks to Garth Watney and Owen Cheng at NASA

JPL for their support in acquiring the STAARS framework

and assisting in getting up to speed on the auto-coder

component to assure our success

Documents

Using Rules-based Statecharts to Automate Satellite Behaviors