Safety Verification of Model Helicopter Controller Using Hybrid Input/Output Automata

1
Safety Verification of Model Helicopter
Controller Using Hybrid Input/Output Automata

• Sayan Mitra
• MIT
• Hybrid Systems Computation and Control
• Prague, Czech Republic
• 2003
• Joint work with Yong Wang (U. Beijing), Nancy
  Lynch, Eric Feron

2
Verification Techniques

• Algorithmic
• Model checking e.g. Alur, et al. 95
• Automatic HyTech
• Essentially for finite-state systems, subclass of
  linear hybrid systems
• Over approximating set of unsafe states Bayen,
  et al. 02
• Deductive
• Invariant assertions, simulation relations e.g.
  Manna, Sipma 98
• Can accommodate infinite-state systems STeP
• Requires human effort
• User interaction

3
Talk Outline

• Introduction?
• Hybrid I/O Automata definitions
• Specification of Quanser
• Safety Verification
• Conclusions

4
The HIOA ModelLynch, Segala, Vaandrager 01, 03

• General, mathematical modeling framework.
• States, discrete transitions
• Trajectories Maps left closed intervals of time
  to variable values
• Support for decomposing hybrid system
  descriptions
• External behavior Models interaction of
  component with environment.
• Composition Synchronizes external actions,
  external flows respects external behavior.
• Levels of abstraction Implementation notion
• Can incorporate analysis methods from
• CS Invariants, simulation relations,
  compositional methods.
• Control theory Invariant sets, stability
  analysis, robust control.

5
Hybrid I/O Automaton

• V U ? Y ? X Input, output, and internal
  (state) variables
• Q States, a set of valuations of X
• ? ? Q Start states
• A I ? O ? H Input, output, and internal
  actions
• D ? Q ? A ? Q Discrete transitions
• T Trajectories for V.

I
O
X
U
Y
H
6
Trajectory Axioms and Executions

• Set T of trajectories is closed under
• Prefix
• Suffix
• Countable concatenation
• fstate, lstate
• Execution fragment ?0 a1 ?1 a2 ?2 , where
• Each ?i is a trajectory of the automaton and
• Each ( ?i.lstate, ai , ?i1.fstate) is a discrete
  step.
• Execution
• Execution fragment beginning in a start state.

7
Model Helicopter System

• Manufactured by Quanser
• User controllers not necessarily safe, can crash
  the helicopter on the table.
• Supervisory pitch controller needed to ensure
  safety.
• Safe operating region
• Saturated actuator outputs Umin or Umax
• Must contend with
• Sensor errors
• Actuator delay

8
Helicopter System
Actuator
Plant
Sensor
?0 , ?1
U
buffer, u
dequeue
now, next
?0 , ?1
Sample
Sample
Sample
Sample
Sample
Command(S)
Command(S)
Command(S)
Supervisor
UserCntrl
Useroutput(Xu)
Useroutput(Xu)
mode, Xs , S, rt
Xu
9
Plant

• Variables
• ?0 Pitch angle
• ?1 Pitch velocity
• Trajectories
• evolve d(?0) ?1
• d(?1) -O2cos ?0 U
• Input bounds
• Umin , Umax
• Safe Region
• S s ?min s.?0 ?max

?0 , ?1
10
Sensor

• Discrete transition
• Sample(?0d , ?1d )
• precondition now next
• and ?0d ? ?0- ?0 , ?0 ?0
• and ?1d ? ?1 - ?1, ?1 - ?1
• effect next next ?
• Trajectories
• evolve d(now) 1
• stopping condition now next

?0 ,?1
Sensor
now, next

Nondeterministic choice
Sample(?0d , ?1d )
11
User Controller

• Arbitrarily bad user
• On receiving Sample,
• Useroutput(Xu)
• Non deterministic choice, Xu ? Umin, Umax

12
Actuator

• Actuator delay Ta
• modeled as a FIFO queue of Supervisor(User)
  outputs
• buffer length Ta / ?
• Enqueue S received from supervisor
• Dequeue u from buffer head,
• u changes discretely
• Made into piece-wise continuous output U

13
Modeling Actuator Delay

• Ta Currently modeled as a single discrete jump
  from Umin to Umax after time Ta.
• Alternatively
• Approximate exponential rise by adding k
  intermediate values in the buffer, for every
  command from the supervisor.
• Output from buffer will change every ?/k time.
• Model as continuous function

Ta
14
Safe Operating Region
?1
S
C
R
U
I
?0
?min
?max
Assumption Cannot cross I in ? time.
15
Supervisor
Sample
Supervisor
Command(S)

• On receiving sample, computes Xs
• If s is above I then Xs Umin
• If s is below I- then Xs Umax
• On receiving useroutput(Xu), computes S
• If mode user then
• If s is in U then S Xu
• Else mode supervisor S Xs
• If mode supervisor then
• If s is in I then S Xu mode user
• Else S Xs

mode, Xs , S, rt
Userout(Xu)
16
Safety Verification

• Assertional Proofs
• Reasoning based on current state of the system
• Finding the invariants is challenging
• Strengthen statement
• Proofs are easy, for proving I
• Base case ? ? I
• Discrete part s ?a s ? D,
• show I(s) implies I(s)
• Continuous part closed t ? T,
• show I(fstate(t)) implies I(lstate(t))

17
Key Lemmas

• All trajectories are closed
• Any trajectory t ? T, ltime(t) - ftime(t) ?.

18
User mode
?1
S
C
A0
A1
A2
R
A?
U
A0 R For 0 t t ? At ? At U ? A?
I
?0
19
User mode

• Safety
• Any reachable state in the user mode is within R.
• Proof
• Discrete part is easy
• Any closed trajectory t ? T, if fstate(t) ? At
  then lstate(t) ? At-ltime(t).

20
Executions in User and Supervisor modes
21
Supervisor mode

• Correct input to plant
• If s is above I then last rt/? entries in
  buffer are Umin
• rt stopwatch for supervisor mode
• Similarly, s is below I- then Umax
• Settling phase rt Ta
• Any reachable state is within C
• All trajectories starting from within R remains
  within C
• Proof similar to User mode
• Recovery phase rt gt Ta
• Any reachable state is within C
• Proof At any point on boundary of C, the vector
  field points inwards

22
Conclusions

• Design of supervisory controller
• Controller has been implemented Ishutkina.
• Specification Language
• Demonstration of HIOA framework
• Specification
• Compositional
• Nondeterminism models uncertainties in devices or
  user inputs.
• Purely assertional proofs
• Discrete and continuous parts
• CS and Control Theory techniques
• Current/Future Work
• Performance guarantees for mobile computing
  algorithms
• Theorem prover support

23
Thank You.Questions ?
24
(No Transcript)
25
Current/Future Work

• Incorporate control theory methods
• Invariant sets, Stability analysis using Lyapunov
  functions, robust control methods.
• More examples
• Systems with more complicated discrete behavior
  and dynamics, e.g. mobile computing, embedded
  systems.
• Develop analysis tools for HIOA programs
• Theorem-provers, automated tools
• As extension to IOA toolset

26
Future Work Case Studies

• Mobile Computing
• Location and Routing algorithms, e.g. Grid Li
  2000
• Objectives
• Performance guarantees under mobility
• Specialize HIOA to model mobile systems
• Control problems
• Quantized double integrator system
• Objective
• Develop and apply analysis methods from control
  theory

27
Future Work Tool Support

• Theorem prover interface
• Automatic translation of HIOA specifications into
  the language of the prover
• Prover tactics and strategies
• Extend IOA Toolset
• Language frontend
• Interface with other tools
• Model-checkers
• Simulators

28
Discrete Communication Among Components
sample control command dequeue
usrCtrl
sensor
sensor
plant
supervisor
actuator
0
29
Other Applications

• Automated transportation systems
• Simple vehicle maneuvers Weinberg, Lynch 96
• PATH automated highway system Branicky,
  Dolginova, Lynch 97 Dolginova, Lynch
  97Lygeros, Lynch 98
• Aircraft control
• TCAS Livadas, Lygeros, Lynch 99
• Spacecraft
• ACME Ha, Lynch, Garland, Kochocki, Tanzman 03
• Robotics
• Lego cars Fehnker, Vaandrager, Zhang 02

30
Helicopter Model and Analysis

• We developed HIOA models for all system
  components Plant, Sensor, Actuator, User
  Controller, Supervisor
• Including realistic dynamics, delays,
  inaccuracies.
• Used the models to help design a safe supervisory
  controller.

31
Language Design

• Additional structure for specifying trajectories
• Variables are either discrete or continuous
• Discrete variables remain constant over
  trajectories
• Describing trajectories
• State space is partitioned into modes
• Continuous variables in each mode evolve
  according to differential/algebraic equations.
• Each mode is specified by an activity