Communication Patterns For Embedded System Design
Communication Patterns For Embedded System Design
System Design
Johan Philips
University of Leuven, Belgium
http://people.mech.kuleuven.be/~jphilips/
Communication Examples
Analog world
I telephone call
I conversation
I oral examination
I leave a note
I sending a letter
I writing on blackboard
I handshaking
Asynchronous vs synchronous
Asynchronous
I takes place outside of real time → time lag
Synchronous
I similar to a conversation → no time lag
willing
I immediacy → no need to wait for reply
representations
I session layer: tie together multiple streams
network
I data link layer: move frames to other node across link
Host Host
Router Router
A B
Data Flow
Application process-to-process Application
Fiber,
Ethernet Satellite, Ethernet
etc.
”IP stack connections” by en:User:Kbrose - Prior Wikipedia artwork by en:User:Cburnett. Licensed under CC BY-SA
Data encapsulation
Data Application
IP
IP data Internet
header
Frame Frame
Frame data Link
header footer
Synchronous model
I single-threaded
executed → scheduling
I e.g. Arduino car
Threaded model
I each task is executed in a separate thread of control
I OS manages threads
Asynchronous model
I tasks are interleaved
Event-driven programming
I no blocking for I/O
I program flow is determined by events
I callbacks to receive notifications
I very common in GUI frameworks
I Reactor pattern to separate event logic
from business logic
when triggered
do {
communicate() % get latest events
coordinate() % react to them
configure() % possibly requiring reconfiguration
schedule() % now do one’s Behaviour
coordinate() % execution could trigger new events
communicate() % that others might want to know about
log()
}
ZeroMQ - zero-em-queue - MQ
adopted from zeromq.org, copyright (c) 2015 iMatix Corporation and licensed under cc-by-sa 3.0
SHERPA project
REQ-REP
Client/Server model
I Client sends request to Server and Hello World
request is received
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
measurements PUB
bind
I Typically used in asynchronised p2p updates
model
I Publisher write data to PUB socket updates updates updates
Subscriber
SUB
Subscriber
new data arrives
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
tasks
Ready!
Ready!
results
PULL
PAIR
Sink Step 3
ROUTER-DEALER
Client
I Asynchronous request-reply
DEALER I N to N communication
I Router sockets adds addressee in
message header to route replies
correctly
ROUTER I Dealer sockets enforce explicit
Server
bookkeeping in application code
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
Patterns on http://zguide.zeromq.org
Node coordination
Publisher
PUB REP
I Synchronise initialisation
(3) (2)
I Separate channel to
(1) bootstrap communication
I Solves late joiner problem
SUB REQ
Subscriber
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
Client Client
I Heartbeating between
Retry Retry peers: e.g. server and its
REQ REQ
workers
I (Basic) discovery of modules
ROUTER ready to provide particular
Queue
Heartbeat
service
ROUTER I Asynchronous
communication between
DEALER DEALER
requester (client), provider
Heartbeat Heartbeat (server) and executor
Worker Worker
(worker)
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
Espresso
bind
I Log all or some
XSUB
Proxy
communication
XPUB (configurable)
bind
I Limit data transfer
connect connect
Further Reading
STD
I Special case of RFC or set of RFCs which has been turned
STDs
All information is publicly available!
IP
Internet Protocol
I Hourglass architecture of the Internet: IP works over many
network types with many (application) protocols on top
I Used by most computer networks today
I IPv4 (32-bit address) vs IPv6 (128-bit address) → allows
3.4x1038 addresses
I Does not provide much service → encapsulate another
protocol within IP
Client Broker
statebe
connect bind
Worker Broker
statefe
images copyright (c) 2014 iMatix Corporation and licensed under cc-by-sa 3.0
messages
I Goals: robust on poor networks, work without centralised
service
Z25 Orchestration Control Protocol (ZOCP) -
https://github.com/z25/pyZOCP
I Goal: control multiple computers in live performances → low
latency, reliability
I Zero configuration, open standards, KISS
Concluding remarks