NC: A Verifiable, Executable Coordination Paradigm for Real-Time Communication

1
NC A Verifiable, Executable Coordination
Paradigm forReal-Time Communication

• Sebastian Fischmeister
• sfischme_at_seas.upenn.edu
• Department of Computer and Information Science
• University of Pennsylvania

2
Real-Time Systems

• Right value at the wrong time can cause an error!

? How to guarantee timeliness in the system?
3
Distributed RT Systems

• Multiple nodes together realize one real-time
  application.

? How to bound communication delays in the system?
Collisions, retransmissions, delays!
? need for a coordination model for controlling
access.
4
Time Division Multiple Access

• TDMA is a method for realizing collision-free
  access to a shared medium.
• Partition access into time slices (slots) and
  rounds.
• Assigns slots to nodes for exclusive access using
  some algorithm.
• Example Round robin with four nodes

5
Flavors of TDMA

• Great for safety-critical systems, but too
  inflexible.
• Still
• Decisions are made at the beginning of the
  round/phase.
• Phase order stays the same.
• Typically independent of the software.

6
Goals of Network Code

• Goals
• Allow close interaction between the application
  and the medium access control.
• Allow developers to program their own access
  control.
• Allow decisions during the communication round.
• Should be apt for safety-critical hard real-time
  systems.

7
Network CodeISCC05

• Executable programmable coordination model for
  real-time communication with a domain specific
  language.
• Split application into program logic
  communication logic
• Communication logic is programmed separately
  (Network Code program)
• An interpreter (Network Code machine) executes
  the program at run time

Node1
Node2
Medium
8
Research Results/Status

• Theory
• Underlying concept and idea of Network Code
  ISCC05
• Verification of Network Code programs RTAS06
• Given a set of programs, are they safe to run
  concurrently?
• Metrics framework for measuring programs
  EmSoft06
• Overhead, throughput, avg. cycle length, avg.
  waiting time
• Composition algorithms for programs submitted
• Given several applications, how can they run
  together?
• Simulation
• In round decisions increase throughput and
  performance. EmSoft06
• Gains are kept despite overhead introduced during
  composition. submitted
• Implementation
• Implementation RTLinuxProRTAS06,TC07Ethernet,
  PIC18FCAN , FPGA

9
How does it work?
10
Example Transmit X in M

• Slot length is 10t.
• Node 1 transmits variable X every 20t in message
  M on channel ch.
• Node 2 receives this message and stores it Y.

t
10
20
0
Sender
Receiver
11
Complex Example

• Transmit a value with temporal replication
  tolerating 2 failures
• Sensor values A to E. (2n1)
• Decide at the end of the round what the sensor
  value is.
• Take the majority vote (e.g., 4,4,3,2,4 is 4)

12
Complex Example Code
Node A La create(MA, A) send(ch,
MA) wait(20) receive(ch, B) wait(10) receive(c
h, C) if(voteDecisive, La) wait(10) receive(ch,
D) if(voteDecisive, La) wait(10) receive(ch,
E) goto(La)
13
System Overview
RT application
Application layer
Value det. layer
Variable space
Network code machine
Hard queue
Soft queue
Dynamic TDMA layer
Message transceiver
14
Data Flow (Hard Values)
RT application
Application layer
Network code program
Value det. layer
Variable space
Network code machine
Hard queue
Soft queue
Dynamic TDMA layer
Message transceiver
15
Data Flow (Soft Values)
RT application
Application layer
Network code program
Value det. layer
Variable space
Network code machine
Hard queue
Soft queue
Dynamic TDMA layer
Message transceiver
16
Verification CheckingRTAS06

• What if I have a bug in my Network Code program?
• ? a verification framework with model checking
• Use operational semantics of instructions to
  model system state.
• Convert program instructions to transformations
  of the system state.
• Check properties are reachability questions using
  model checking.

Prgm 1 La wait(20) send(_,_,_) if(guardX,
La) wait(10) send(_,_,_) goto(La)
Prgm 2 Lb wait(10) send(_,_,_) wait(30) goto(
Lb)
17
Example Properties

• Integrity checks
• All guards present
• Valid jump addresses
• Successor address
• Consequential code

• Behavioral checks
• Non-empty send
• Local message lifecycle

• Distributed checks
• Collision-free communication
• Schedulability
• Non-empty receive
• Message reception within timeout

18
Metrics FrameworkEmSoft06

• What is the overhead? What is the throughput?
  What is the cycle?
• Convert the Network Code Program into a timed
  tree communication schedule.
• Compute metrics on the tree schedule using DFS
  model checking.
• Timed tree communication schedule
• Nodes encode messages releases and delays
• Transitions encode mutually excl.
  decisions(exhaustive, deterministic)
• Leaves cause a reset

19
Example Metrics

• Longest cycle length longest branch
• Guard overhead
• End-to-end constraints for messages
• Probabilistic tree schedules
• Average cycle length average branch length
• Average waiting times

20
Is it better?
21
Inverted Pendulum

• Pendulum sitting on a cart with one degree of
  freedom.
• Measure the angle w.r.t. to straight up.
• The cart moves horizontally to balance the
  pendulum.
• Temporal replication to tolerate two faults
• 5 measurement units (A to E)
• Report measurements to the controller.
• Controller updates the kart at the round.

22
Simulation Results
Standard schedule
Network Code is better
23
Simulation Results
Mean time to failure
With an increase in the mean time to failure,
standard TDMA stays the same. Network Code
utilize this increase in reliability.
24
Implementation Measurements

• Given the shortest program, what is the fastest
  execution rate?
• Output queue must not overflow.
• Input queue must not under-/overflow.
• Slot structure must not be violated.
• RTLinuxPro direct link (100 MBit/s)
• 10 latency increase due to computation time
• 2.96MByte/s with a 99 guarantee of a successful
  transmission
• 2.65MByte/s with 99.999 guarantee
• Interrupts preempt instructions, cause jitter,
  cause delays.
• Send() instruction 372ns (39.47), 733ns (99),
  19090ns (99.999)
• gt FPGA! (10us)

25
Conclusions

• Communication behavior differs among
  applications custom protocols/schedules can
• Significantly improve the applications
  performance
• Incorporate/guarantee new properties at the
  communication layer
• Network Code allows programming custom TT
  communication behavior.
• Programs are checkable, guarantee properties in
  the distributed system.
• Programs are measurable with tree schedules.
• Can run real-time and non-real-time traffic on
  the same network.
• Future work multi-resource tree schedules and
  resource DSLs, program generation, development
  methodology

26
Other/Past Research

• Logical execution model has deficits when
  considering communication.
• Task chainsDASC04
• Case studyRTAS05
• How to deterministically reconfigure RT software?
• Use virtualization and separate behavior
  functionalityECRTS05
• Are mobile agents systems secure? (year 2000)
• No!MA01
• How to build efficient proactive location-based
  systems?
• Decentralized architectureLNAI
• Use notification servicePERCOM03

27
Outlook
28
DSLs Interfaces
Current Approach

• What are good abstractions for resources, what
  are good DSLs?
• What makes the interface of a software
  component? Is the DSL the interface?
• How can we generate code for a component?
• How do we provide hardware support for DSLs?
  (e.g., programmable memory)