Small Satellite Conference 2014 Using Rules-based Statecharts to Automate Satellite Behaviors

Transcription

1 Using Rules-based Statecharts to Automate Satellite Behaviors Kenneth Center, PhD Director of Advanced Software Technologies PnP Innovations

2 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 p2

3 Autonomous Mission Manager (AMM) Application of Architecture High Value Assets with Hosted Payloads Co-Orbital Visitor Space-Space Surveillance Earth Observing Satellites CubeSats Dynamic Joining of Autonomous Federated Assets Enable Space Domain user community to extract maximum utility from assets Taskable Ground-based Sensors Ground Tasking & Processing Sites Airborne Sensors Ground Network Direct interactions between assets and autonomous decision-making remove human operator latency and reduce response times Operators specify operational rules in natural language to create/tailor system behavior to mission needs Rules stored in libraries for reuse p3

4 Adaptive Scalable Portable Infrastructure for Responsive Engineering (ASPIRE) Processor Manager Satellite Flight Systems Data Directory Data Registrar Data Query support Aspire core component address management Time distribution Satellite Hardware Aspire Components Mission Software Network Adapter(s) Federated Assets Cluster Ops Distributed Functionality Cross-Links 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 S-G Links Ground Infrastructure (Over Ethernet) Command & Control Data Processing Automated Operations Network Messaging p4

5 Messaging Services System (OS) Services AMM Data Architecture Layers The latest addition API Assessment Planning/ Scheduling Autonomy Services Execution Rules Rules Fusion Goals Rules Response Tactics Tactics Tactics API API Subsystem Layer Services Pointing Power Comm Thermal GNC API API API Device/Application Support Layer Services Physics- Based I/Fs Planning Support Metadata Repo Remote Files Misc Utility API API Att/Rate Sensors Power Switching Platform Hardware React n Wheels Radios Thrusters Data Store Sensors Sensors Sensors API Aspire Middleware p5

6 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 p6

7 State Machines to 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) p7

8 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 Model Checking State-based Framework Test Harness Autocoding STAARS was used to specify autonomous operations for most phases of the JPL Curiosity mission p8

9 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 nonproprietary 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 Model.XML Input Parser JPL Autocoder C++ C - QF2 C - QF3 C - MSL Promela/ C Python Drools Drools-Aspire back-end added Model.cpp Model.c Model.c Model.c Model.c Model.pml Model.py Model.drl p9

10 MagicDraw UML p10

11 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 p11

12 Relationship to Other AMM Capabilities Satellite Telemetry Events Auto-Coded Drools Statechart IntelligentAgent Class Drools JAspire API JAVA Aspire Reliable Message Transport Layer Satellite Resources Planners 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 p12

13 xteds Structure The standard xteds header referencing the syntaxenforcing 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) p13

14 Drools Pattern Generation AMM xteds Definitions xteds Data Sheets define bindings between message variables and Drools knowledge base facts declare RequestWeatherPrediction extends interfacename = "ICourseOfAction", messagetype = Notification, messagearrival = EVENT, globalvariablename = "grequestweatherprediction", role = Provider ) MissionTime : type = UINT32 ) WeatherType : type = STRING ) end global RequestWeatherPrediction grequestweatherprediction Statechart logic results in rules synthesis to manage state actions and transitions rule "Ceiling2500ft" salience 200 when CloudCeilingDataMsg( Ceiling < ) then insertlogical( new Ceiling2500ft() ); logger.debug( "Ceiling2500ft: complete" ); end rule "BeginForecastCeilingToEvaluatePlanBTransition" salience 10 when cloudceilingdatamsg : CloudCeilingDataMsg() InForecastCeiling() Ceiling2500ft() then retract( cloudceilingdatamsg ); insert( new InForecastCeilingToEvaluatePlanBTransition() ); logger.info( "BeginForecastCeilingToEvaluatePlanBTransition: complete" ); end p14

15 Relationship to AMM STAARS Define Asset/System Behaviors/Responses Systems Engineers or Satellite Operators Graphical UML STAARS State Sim SDT AspireStudio AutoCode Validation Cycle bdstudio BAIT Languages SCL C/C++ Promela Drools Deploy System AMM xteds Definitions Aspire Messaging AMM SOA Modules AMM Architecture Space Segment Ground Segment 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 p15

16 Process Flow Select Mission Modules from AMM Library OPERATIONAL PROCESS Create flight software load Upload to satellite Execute Dynamically update statechart during execution Start with a statechart template Interactively specify states & transitions Dependency tree selects necessary support services DEVELOPMENT PROCESS Map actions and guards to Aspire Messages & AMM Services Select Statechart for use on a Mission Auto-generate Code Commit Generated Module to Library SPIN-check to verify correctness Deploy the statechart in test environment with selected Mission Modules Verify proper operation p16

17 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 p17

18 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 p18

19 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 p19

20 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 p20

21 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 p21