1. FSM Controllers ENGR #8 2016

2. Menu Building a Controller for the traffic lights.
Mealy FSMs vs Moore FSMs,
Factored States
Admin:
Lab Signup, labs and assignments
Laptops in lectures
Class Representative

3. Abstraction Typically, a Finite State Machine is an abstraction:
Simplification
Capturing the significant aspects of the behaviour
Leaving out unimportant details
Describes the system at a particular level.
eg: the door:
how far open the door is,
how big the door is,
what kind of key it uses
how hard you have to push to close it. ….
eg the website
no details of the actions on each page

4. Kinds of Finite State Machines.
Lots of different varieties of Finite State Machines.
Describing how a passive system works.
states the system can be in,
actions on the system that change its state.
eg: the door, the website, a DVD player,
Can use the FSM description to
Design the system
Explain the system to users
Construct a simulation of the system ….
open
closed
&
locked
pull
push
turn key
turn
key

5. Kinds of Finite State Machines.
Describing/specifying an active system
states the system can be in
input/signals/sensors that the system may respond to
actions that the system will perform
eg: an autonomous vehicle with sensors
a controller for a robotic toy
an NPC in a video game
a controller for a lift (the assignment) …
begging
patted
start
begging
stop
stop
timer
timer
walking
waiting
turning
round
patted
IR sensor
start walk, start timer(30)
start turning, start timer(10)

6. Kinds of Finite State Machines.
Specifying a pattern or a language
states representing different points in the pattern
characters/words/signals that are the next component of the pattern
eg: Regular expression matching in an editor
(SW|NW|EC)EN3[0-9][0-9]
Sequence of the sounds for different phonemes in a word
Simple command language for an adventure game.
(Fundamental to some algorithms for text and language.)
Specifying a communication protocol
states representing different stages in the communication
message types that are expected or required at each stage

7. ? Controllers Devices to control systems. Controller
Could be hardware, but usually software, might be a microprocessor or a large computer.
Controller gets input from the system
Controller performs actions on the system to change its behaviour
Note: two different systems here:
controller and the controlled system.
Might need to design both, but they are separate issues.
System:
robotic toy
autonomous vehicle
lift
traffic lights
vending machine
animation of NPC
etc.
Controller ?
Signals/sensors
actions

8. Simple Reactive Controllers.
Controller drives the system:
Input: Signal/sensor from the system triggers an action
Output: Action, reacts to the signal
Same response to a sensor, every time
Very limited
System:
robotic toy
autonomous vehicle
lift
traffic lights
vending machine
animation of NPC
etc.
Signals/sensors
Controller
Sensor1 ⇒ action1
Sensor2 ⇒ action2
Sensor3 ⇒ action3
Sensor4 ⇒ action4
actions

9. FSM Controllers. Controller drives the system: System: Controller
Input Signal/sensor from the system
triggers an action
and changes state
States represent the history of what has gone before to enable different responses to same sensor at different times
Much richer behaviour.
System:
robotic toy
autonomous vehicle
lift
traffic lights
vending machine
animation of NPC
etc.
Signals/sensors
Controller
sensor
action
actions

10. Example: Traffic light controller
Sensors?
Actions?
States?
what are the different conditions where the controller should act differently?
eg:
should it always change the lights when a car drives up?

11. States for traffic light controller

12. States for traffic light controller
Sensors: carEW, carNS, timer
Actions: EW:grn, EW:amb, EW:red, NS:grn, NS:amb, NS:red, setTimer(n)
What's the problem with this? EW Go EW
Stopping NS Go
carEW
→ NS:amb
→ setTimer(3)
carNS
→ EW:amb
→ setTimer(3)
timer
→ EW:red
→ NS:grn N NS
Stopping
timer
→ NS:red
→ EW:grn W E S

13. States for traffic light controller
Sensors: carEW, carNS, timer
Actions: EW:grn, EW:amb, EW:red, NS:grn, NS:amb, NS:red, setTimer(n)
Why have we duplicated the actions?
EW Go
ready
EW Go EW
Stopping
NS Go
NS Go
must
change
carNS
→ EW:amb
→ setTimer(3)
timer
→ EW:red
→ NS:grn
→ setTimer(15)
carEW
timer
timer
→ NS:amb
→ setTimer(3)
→ EW:amb
→ setTimer(3)
timer
timer N
EW Go
must
change
EW Go NS
Stopping
NS Go
ready W E S
timer
→ NS:red
→ EW:grn
→ setTimer(15)
carEW
→ NS:amb
→ setTimer(3)
carNS

14. Mealy or Moore? Mealy FSM: Moore FSM: What's the difference?
Action associated with transition (state and sensor input):
"if in this state, and this input happens, then
do this action and change to that state.
Moore FSM:
Action associated with state only:
"if in this state, this input happens, then change to that state"
"if enter this state, then do this action"
What's the difference? EW
Stopping
NS Go
timer
→ EW:red
→ NS:grn EW
Stopping
NS Go
timer
EW:red
NS:grn

15. Mealy vs Moore Moore FSM may be simpler: BUT……. EW Go ready EW Go EW
Stopping
NS Go
NS Go
must
change
carNS
timer
carEW
EW:red
EW:amb
NS:grn
setTimer(5)
setTimer(30)
timer
timer
timer
timer N
EW Go
must
change
EW Go NS
Stopping
NS Go
ready
NS:red
timer
carEW
NS:amb
carNS
EW:grn
setTimer(5)
setTimer(30) W E S

16. Mealy or Moore? Mealy FSM: Moore FSM: What's the difference?
Action associated with state and input:
"if in this state, and this input happens, then
do this action and change to that state.
Different actions into a state may have different effects
Moore FSM:
Action associated with state only:
"if in this state, this input happens, then change to that state"
"if enter this state, then do this action“
All actions into a state have same effect
What's the difference?
NS turn
right
timer
→ NSright:red
→ NS:grn EW
Stopping
NS Go
timer
→ EW:red
→ NS:grn
NS turn
right EW
Stopping
NS Go
timer
timer
EW:red
NS:grn

17. Mealy or Moore? If all transitions into a state have the same actions,
⇒ Use a Moore FSM – it's simpler
But if the transitions into a state have different actions
Moore FSM ⇒ Have to make more states, and duplicate transitions
Mealy FSM ⇒ Can keep fewer states
Can mix both! UML Finite State Diagrams allow both kinds of actions
NS turn
right
timer EW
Stopping
NS Go
NS Go
timer
EW:red
NSright:red
NS:grn
NS:grn