Programming Lift Control Logic in Hume

1
Programming Lift Control Logic in Hume

• G. Patai, P. Hanák
• ltpatai_at_iit.bme.hugt, lthanak_at_inf.bme.hugt
• Dept. of Control Eng. and Information Technology,
• Budapest University of Technology and Economics

2
Background

• Masters thesis embedded vs. functional world
• Language candidates ? Hume
• A simple application example
• Special hardware
• Porting the language
• Lift control design implementation
• Comparison with C

3
Embedded systems

• Autonomous programmed systems
• Special requirements
• High dependability
• Robustness
• Limited response time
• Scarce resources
• Concurrency

4
Embedded development

• Prevailing languages assembly, C, C
• Current problems
• Abstraction hole between design and code
• Long source code, error prone development
• Unsafe code
• Poor verifiability and testability
• Development vs. target platform
• Cross compiling
• Mostly printf()-debugging, tracing

5
Drawbacks of functional languages

• Hard to represent complex state
• Lack of timeliness
• Cumbersome communication (between program parts)
• Limited I/O capabilities
• Limited efficiency
• Acceptance

6
Pure functions vs. applications
?
In
Out
Multiple peripherals? Timing?
Buttons
??
Sound memory
Microphone
Speaker
7
Hume a possible solution

• Hybrid, fully declarative approach
• Logic (purely) functional boxes
• Communication and state wires
• Time and space guarantees
• Fully customisable I/O
• Seamless integration with C
• Native object code through C

8
Hume vs. our problems

• Hard to represent complex state?Explicit,
  separate wires
• Lack of timeliness? Clock sequencing through
  proper rules
• Cumbersome communication?Tokens on wires
• Limited I/O capabilities?Extend with C snippets
• Limited efficiency? Native object code,
  lightweight runtime

9
Lift Control

• Simple application
• Low-resource hardware

10
Design

• Orthogonal, parallel functionality
• Requests
• Cabin
• Door
• Separate components
• Logic
• Internal state
• Communication
• I/O

R
C
request
D
clock
11
Hume implementation

• Components
• State information wire loops
• Boxes transformation rules
• Coordination wires between boxes and I/O nodes
• Complexity
• Request manager 5 rules
• Cabin 9 rules, 9 states
• Door 8 rules, 4 states

12
Example cabin states
Moving UP
Stopping UP
Stopped UP
Retiring UP
Idle
Retiring DOWN
Stopped DOWN
Stopping DOWN
Moving DOWN
13
Example request manager
(requests, floor_num, door_open)

• Internal staterequests,floor number
  cache,door state cache
• Caching reduces communication
• Five rules of operation, i.e. state transitions
• 4 inputs, 3 outputs

• Request ahead?
• Stop here?
• Door opened
• Door closing
• Incoming request

14
Request manager rule 1
((f, o, rs), , MsgAskAhead ad, ) ? ((f, o,
rs), MsgRequestAhead (isAhead rs f ad), )
Any request ahead?
R
C
Yes/No
15
Request manager rule 2
((f, o, rs), , MsgAskCurrent af ad, )
? ((af, o, rs), MsgNeedToStop (needToStop rs af
ad), )
Stop at current floor?
R
C
Yes/No
Store floor number
16
Request manager rule 5
D
Notify if current floor
R
Request
Notify if other floor
C
If enabled, store request and send notification
17
The lift in action
18
Experiences and future

• Speed is likely to be satisfactory in many
  applications
• Object code size is a major bottleneck
• Problems successfully addressed while benefiting
  from the functional approach
• Possibility of better tool support true visual
  programming (executable design), verifiers,
  debuggers, testers, emulators possibly using GME
• All in all a promising direction