Post on 13-Mar-2022
Small Satellite Conference 2014
Using Rules-based Statecharts to Automate
Satellite Behaviors
Kenneth Center, PhD
Director of Advanced Software Technologies
PnP Innovations
Ken.Center@PnPInnovations.com
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
p3Small Satellite Conference 20148/4/2014 10:55 AM
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
p4Small Satellite Conference 20148/4/2014 10:55 AM
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
p5Small Satellite Conference 20148/4/2014 10:55 AM
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…
p6Small Satellite Conference 20148/4/2014 10:55 AM
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
p7Small Satellite Conference 20148/4/2014 10:55 AM
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)
p8Small Satellite Conference 20148/4/2014 10:55 AM
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
p9Small Satellite Conference 20148/4/2014 10:55 AM
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
p11Small Satellite Conference 20148/4/2014 10:55 AM
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
p12Small Satellite Conference 20148/4/2014 10:55 AM
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
p13Small Satellite Conference 20148/4/2014 10:55 AM
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)
p14Small Satellite Conference 20148/4/2014 10:55 AM
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
p15Small Satellite Conference 20148/4/2014 10:55 AM
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”
p16Small Satellite Conference 20148/4/2014 10:55 AM
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
p17Small Satellite Conference 20148/4/2014 10:55 AM
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
p18Small Satellite Conference 20148/4/2014 10:55 AM
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
p19Small Satellite Conference 20148/4/2014 10:55 AM
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
p20Small Satellite Conference 20148/4/2014 10:55 AM
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
p21Small Satellite Conference 20148/4/2014 10:55 AM
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