Dataflow-based heterogeneous code
generator for IoT applications
Gábor Paller1
Endri Bezati2
Nebojša Taušan1
Gábor Farkas1
Gábor Élő1
(1) Széchenyi István University, ISREG (Hungary)
(2) streamgenomics Sarl (Switzerland)

“The Internet of things (IoT) is the network of
devices such as vehicles, and home appliances
that contain electronics, software, sensors,
actuators, and connectivity which allows these
things to connect, interact and exchange data.”
(Wikipedia)

Heterogeneity
● Heterogeneity of devices
– Vertical: amount of resources (memory, CPU power,
etc.) that the device has
– Horizontal: differences of the services provided by
the device (e.g. WiFi)
● Heterogeneity of the platforms
– No dominant IoT platform as of beginning of 2019
– Each IoT platform requires different coding style

Research question
● Can we do it model-based?
– Model suitable for how IoT domain experts think
● IoT domain experts: factory engineers, civil engineers, automation
designers …
● Software/hardware engineers also come into the picture when the
actual IoT system is designed/implemented
● Can we generate code?
– Instead of just creating the 1000th IoT platform
– Possibility of supporting any IoT platform/device
– And any mixture of those (like parallel code generation for a
number of devices/platforms)

Reality check
Design environment: Tridium Niagara, source: CC North Ltd. © 2015

Search for a base system
● Systems studied: Node-RED, Internet of Things Work-bench (IBM),
Spacebrew, TASTE, Caméléon, Vorto, ANKHOR FlowSheet, Orcc
● Models studied: data-flow, component-based
● Orcc (http://orcc.sourceforge.net/) was selected:
– It is completely open-source under the BSD license.
– Its compiler backends are able to generate code for a wide variety of targets
from FPGAs to relatively high-end runtimes like Java.
– Orcc does not enforce any mandatory runtime unlike systems like Node-RED
enforces web runtime. 2 .
– It is based on the Eclipse platform that makes it highly extensible.
– Its data formats have been standardised (ISO/IEC, 2012). This standard
describes the dataflow network’s representation in XML format that Orcc
implements.

Orcc Environment
Typical CAL working environment
Package Explorer: Orcc Projects
XDF : Network Editor
CAL source code editor
Orcc Environment

1. consumption & production of tokens 2. state
3. multiple actions
4. guards
5. priorities
Motivation & Introduction: CAL Dataflow – crash course
actor Add () A, B ==> X:
action A:[a], B:[b] ==> X:[a+b] end
end
actor Merge() A, B ==> X:
action A:[a] ==> X:[a] end
action B:[b] ==> X:[b] end
end
actor Split() A ==> P, N:
action A:[a] ==> P:[a]
guard a >= 0 end
action A:[a] ==> N:[­a]
guard a < 0 end
end
actor Sum() A ==> X:
s := 0;
action A:[a] ==> X:[s]
do
s:= s + a;
end
end
actor BiasedMerge() A, B ==> X:
CopyA: action A:[a] ==> X:[a] end
CopyB: action B:[b] ==> X:[b] end
priority CopyA > CopyB; end
end
actor FSM() A, B ==> X:
Pos: action A:[a] ==> X:[a] end
Neg: action B:[a] ==> X:[­a] end
schedule fsm s0:
s0 (Pos) ­­> s1;
s1 (Neg) ­­> s0;
end
end
5. Finite State Machine
Motivation & Introduction

Orcc-IoT
● Gaps:
– Orcc backend is homogeneous (all the code is generated
by one code generator) – this does not satisfy the
heterogeneity requirement
– Code generators more suitable for IoT:
● Server-side Java (Spring flavour was selected)
● Plain Java (once supported by Orcc but removed since)
● Embedded C (supported by Orcc but does not generate
communication code with the server)
– Actor library (might be possible to realize with Eclipse
features)

Describing the heterogeneity

Describing the heterogeneity (2)

Subgraph creation - before

Subgraph creation - after

Current state of implementation
● Heterogeneous compiler implemented
– Consumes the hardware description
– Cuts the data-flow graph into pieces
– Inserts ports
– Invokes backends
● Spring-Java backend implemented
– Generates server-side Java code (Spring flavour)
– Integrates with Azure cloud (event queues, container generation, deploy
scripts …)
● Plain Java backend reinserted
– Generates code that talks to the server code generated by Spring-Java
backend

Architecture of the generated code
Azure cloud
Docker
container
image
Docker container
Websocket
adapter
Azure
EventQueue #1
Azure
EventQueue #2
Azure
EventQueue #3
Code
generated from
the CAL network
JVM
Code
generated
from the
CAL
subnetwork
Websocket
connection
Generated by plain Java backend Generated by Spring-Java backend

ToDo
● Project ends at 30th of June, 2019
● Till then:
– C backend (part of Orcc) needs to be brought into
the architecture
– Actor library
– Complete pilot project
● An entire real-world IoT project implemented with Orcc-
IoT

The day after
● The entire project will be open-source
– Currently hosted on gitlab.com but as a private
repository
● Ready to pass the baton to interested parties

Demo at 22nd
of February, morning session!