Distributed control for fault tolerance in multispacecraft missions

1
Distributed control for fault tolerance in
multi-spacecraft missions

• Leo HartmanCanadian Space Agency
• leo.hartman_at_space.gc.ca

2
Introduction

• Basic idea
• Use a general purpose goal-oriented and fault
  tolerant execution environment to encode mission
  objectives and alternative way in which they can
  be achieved
• Motivation
• Increase level of autonomy
• Improve mission reliability
• Reduce cost
• reduce manual intervention from ground station

3
Outline

• Goal decomposition hierarchies
• Fault tolerance Discovery / join protocols
• Mission configuration
• Resource groups
• Implications for operations
• Conclusion

4
High level view

• Goal decomposition hierarchies
• Encodes alternative ways of achieving goals
• Reacts to changes in environment or internal
  state
• Fault tolerant discovery / join protocols
• Track resource availability
• Mission configuration
• Allocation of resources to mission objectives
• Recomputes allocation in the case of faults
• Resource groups
• Peer groups able to address mission objectives
• Can operate independently of each other
  e.g., in case of faults
• Limit search for viable mission configurations
• Distributed control
• Autonomous selection of approach to be tried to
  address a mission objective
• Resource groups can act autonomously to
  distribute tasks and address mission objectives

5
Goal decomposition hierarchy

• A goal decomposition hierarchy
• Encodes alternative ways of achieving goals
• Reacts to changes in environment or internal
  state
• Searches for decompositions that return "success"
• Goal decomposition structure
• goal precondition
• decomposition1 serial or parallel
• gating precondition
• subgoal11 subgoal12
• decomposition2
• Example
• buyMilk haveMoney?
• walkToBuyMilk serial
• distance to store lt .5km
• putOnShoes leaveHouse walkToStore
• driveToBuyMilk serial

6
Fault tolerance

• Discovery / join protocols
• Provide mechanisms for clients to find services
  without
• a priori configuration
• Registrars
• Keep track of available services / resources
• Registers services
• Maintains service leases
• Looks up services for clients
• Services
• Broadcast requests for registrars
• Request lease from one or more responding
  registrars
• Transmit access info
• Clients
• Broadcast request for registrars
• Send request for candidate services to one or
  more responding registrars
• Send service request to one or more services
  identified by registrar

7
Mission configuration

• Requirements
• Mission objectives such as
• Payload operations
• Onboard computing and communications tasks
• Maintenance of adequate onboard power
• Maintenance of orbit and attitude
• Other system housekeeping operations
• Resources
• Power, memory, processors and processor time,
  onboard subsystems, communication channels and
  bandwidth
• Mission configuration
• Allocation of resources to requirements
• Part of GDH computes the mission configuration at
  the beginning of the mission
• GDH reactively recomputes configuration when
  resource availability changes

8
Resource group hierarchy

9
Resource group hierarchy

• Resource group
• A collection of subgroups or primitive resources
  (that are not more finely divided)
• The basic entity that accepts a mission
  requirement and attempts to satisfy it
• Resource group hierarchy
• Requirements propagate within resource groups and
  down to resource subgroups
• The resource group hierarchy partitions the set
  of resources in order to control communication
  during the (re)computation of a mission
  configuration.
• Lateral decompositionA resource can broadcast a
  requirement or a decomposition of it to its peers
  within the group.
• Vertical decompositionA resource can broadcast a
  requirement to its subgroups

10
Distributed control

• Requirements are distributed down the physically
  distributed resource group hierarchy
• Attempts to satisfy a requirement occur
  independently of faults or loss of communication
  that partition the resource group hierarchy.
• Low level coordination between concurrent
  primitive resources occurs through shared memory.
• Peers within a resource group are not dependent
  on a fixed master containing the group or within
  the group.

11
Implications for operations

• GDH's can implement a variable level of autonomy.
• GDH's can
• Explicitly model requirements, resources and how
  they are related
• Encode the autonomous response to faults or
  communication partitions
• Encode transition to a safe hold mode pending
  intervention
• Encode requests for operator confirmation of
  critical actions
• Tasks for human operators shift from tedious, low
  level control to system performance monitoring.
• Implementation of autonomous responses allows
  more time for human operators to address serious
  faults.

12
Conclusion

• GDH provides reactive goal-oriented behavior.
• Discovery / join protocols track resource
  availability in a fault tolerant way.
• Mission configuration provides an explicit model
  of requirements and allocated resources that a
  subset of the GDH reactively (re)computes.
• Resource group hierarchy
• Limits the search for a mission configuration
• Distributed control
• Autonomous fault recovery responses
• Robust against partitioning events
• Implementation
• A java implementation for laboratory development
  and a FPGA implementation on candidate space
  hardware are underway.

13
(No Transcript)