Dataﬂow-based Heterogeneous Code Generator for IoT Applications

abor Paller

, Endri Bezati

, Neboj

sa Tau

san

, G

abor Farkas

and G

abor

echenyi Istv

an University, Information Society Research & Education Group, Egyetem t

er 1. Gy

or, Hungary

streamgenomics Sarl, EPFL Innovation Park, B

atiment C, Lausanne, Switzerland

Keywords:

Dataﬂow, Code Generator, IoT, Eclipse, IDE, Orcc.

Abstract:

The latest wave of connected digital systems, nowadays called Internet of Things (IoT) promises various

gains, especially in terms of signiﬁcant ease of data access. A large number of different platforms for IoT

applications, however, makes their development difﬁcult and time-consuming leading to projects that are failed

to be on time, on budget or fully completed. To address the platform heterogeneity, this paper presents the

ongoing work on development environment called Orcc-IoT. Orcc-IoT facilitates the development of IoT by

combining dataﬂow modelling language, heterogeneous code generator and the library of ready-made IoT

actors. The utilisation of Orcc-IoT in development is expected to increase the quality, and to reduce the

development costs and time-to-market of IoT applications.

1 INTRODUCTION

The adoption of connected digital systems (com-

monly known as Internet of Things, IoT) is still slow

due to their high complexity. Factors contributing

to the complexity include security, energy efﬁciency,

immaturity of communication technologies and het-

erogeneity of platforms. None of the hundreds of dif-

ferent IoT platforms reached the sufﬁcient footprint

so that a dominant platform can be identiﬁed. This

heterogeneity makes application development a costly

and time-consuming enterprise with the constant risk

that the application must be ported from one platform

to another.

The heterogeneous platform problem of IoT appli-

cations can also be argued with the ﬁndings from the

scientiﬁc literature. For example, the (Tau

san et al.,

2016) study reveals heterogeneous platforms as one

of the requirements for the development of modelling

languages in embedded systems domain. The (Giang

et al., 2015) study suggests that there are two dimen-

sions of the platform heterogeneity in IoT application

domain. These are:

• vertical - shows the amount of resources the de-

vice has. For example a certain device may have

more computing power or memory than the other.

• horizontal - shows differences in services pro-

vided by the device. For example a certain device

may have an embedded A/D converter or a certain

network adapter (e.g. WiFi).

An overview of IoT challenges presented in

(Gazis et al., 2015) reveals two aspects of device in-

teroperation. The ﬁrst is technical and denotes how

to enable the interoperation of heterogeneous devices.

Second is semantic and denotes how to enable the

seamless exchange of information among heteroge-

neous devices. Besides technical and semantic in-

teroperation of heterogeneous devices, the (Yaqoob

et al., 2017) study also identiﬁes the pragmatic as-

pect. The pragmatic aspect concerns with the capa-

bility to observe the intention of heterogeneous par-

ties involved in the interoperation.

To address the heterogeneity problem of IoT ap-

plication development, this paper presents the on-

going work on Integrated Development Environment

(IDE) called Orcc-IoT. The Orcc project (Yviquel

et al., 2013; Sourceforge, 2014) has started in 2010

and it targets signal-processing applications. Our

project, Orcc-IoT builds on Orcc with additional fea-

tures that are speciﬁc for the IoT problem domain.

The features include the improvements of the graphi-

cal Data-Flow Language (DFL), novel code generator

for heterogeneous platforms and the library of ready-

made IoT components or actors.

A motivational example for the selection of

dataﬂow paradigm for our DSL is presented in Figure

1. This example shows an Air Handling Unit (AHU)

IoT system with sensors and actuators designed with

426

Paller, G., Bezati, E., Taušan, N., Farkas, G. and Él

o, G.

Dataﬂow-based Heterogeneous Code Generator for IoT Applications.

DOI: 10.5220/0007496804260432

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 426-432

ISBN: 978-989-758-358-2

the popular Niagara IoT workbench

. The AHU con-

trols supply and return air ﬂows and several character-

istics of each ﬂow are measured. The measurements

are typically cyclically collected, analysed and actua-

tor values are computed. The calculations often fol-

low the ﬂow of material in the system (in this case,

the ﬂow of air).

One example application for the AHU engine is

depicted in Figure 2. This shows the ﬂow of data

from one processing element to another passing the

control among the devices indicating that the dataﬂow

paradigm can be used efﬁciently for these types of ap-

plications.

This ﬂow-like nature of IoT data is indicated in

scientiﬁc sources. Several realistic use cases in differ-

ent application domains are presented in (Yasumoto

et al., 2016) to argue for the dataﬂow paradigm. In

the domain of high-speed computing, the dataﬂow de-

sign environments are most widely used, according

to (Milutinovi

c et al., 2015). Finally, (Giang et al.,

2015) use distributed dataﬂow for their framework

where each device executes only part of the full ac-

tor network. All these characteristics indicate that the

dataﬂow paradigm can be used efﬁciently for IoT ap-

plications.

An approach alternative to the dataﬂow model

is the component-based model, illustrated here by

ThingML (Harrand et al., 2016). The component-

based model concentrates on the components, their

interfaces with each other and their functional de-

scription which is often state machine-based. The

component-based model is not able to expose the par-

allelism existing in the system to the degree provided

by the dataﬂow model. While IoT systems are rarely

as demanding with regards to processing performance

as signal processing applications which is the main

use case for the dataﬂow model, the extreme scala-

bility required by the large amount of endpoints (e.g.

sensors, actuators, etc.) often makes server imple-

mentation challenging. Automatic generation of par-

allel implementation facilitated by the dataﬂow model

may simplify these server implementations signiﬁ-

cantly.

This paper is structured as follows. Section 2 de-

scribes the base system we chose for our dataﬂow-

based IoT design environment and how we propose

to extend it. Section 3 discusses a key component

of the extended system, the heterogeneous dataﬂow

compiler. Conclusions and further work are proposed

in section 4.

https://www.tridium.com/

2 Orcc IoT EXTENSIONS

Today, there are literally hundreds of IoT platforms

proposed. These software stacks offer data inges-

tion/sending from/to the endpoints, data management,

visualisation and device management features, in-

cluding alarms. Some are offered as installable soft-

ware packages, some are cloud services. So far no

dominant player emerged in the ﬁeld, making appli-

cation development a risky investment.

The approach to IoT application development,

presented in this paper, is to take a high-level ap-

plication model and generate code from this model

for the target platforms. Following the considerations

presented in section 1, we have chosen the dataﬂow

paradigm as high-level application model and devel-

oped the DFL to represent the applications.

Instead of developing the environment from

scratch, existing dataﬂow/component design environ-

ments were analysed. The following environments

were studied: Node-RED, Internet of Things Work-

bench (IBM), Spacebrew, TASTE, Cam

eon, Vorto,

ANKHOR FlowSheet and Orcc. The analysis re-

sulted in the selection of the open RVC-CAL Com-

piler (Orcc) (Yviquel et al., 2013; Sourceforge, 2014)

as base development environment. The main advan-

tages of Orcc over the evaluated systems are the fol-

lowing:

• It is completely open-source under the BSD li-

cense.

• Its compiler backends are able to generate code

for a wide variety of targets from FPGAs to rel-

atively high-end runtimes like Java. Orcc does

not enforce any mandatory runtime unlike sys-

tems like Node-RED enforces web runtime.

• 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 dataﬂow net-

work’s representation in XML format that Orcc

implements.

After having selected Orcc as base system, a gap

analysis was performed among the features required

for the IoT dataﬂow and those offered by Orcc. The

most relevant gaps were the following:

• Orcc backend code generation is strictly homoge-

neous. When code is generated for an application

dataﬂow network, one backend is selected and all

the code is generated by that backend. This does

not satisfy the heterogeneity requirement of IoT

systems. The IoT version of Orcc must be able

https://nodered.org/

Dataﬂow-based Heterogeneous Code Generator for IoT Applications

427

Figure 1: Air Handling Unit IoT system designed with Tridium Niagara (source: CC North Ltd.

2015).

Figure 2: Example dataﬂow application for the AHU unit.

to assign parts of the dataﬂow graph to different

backend code generators and generate code for

each IoT system elements.

• The current public Orcc version is very strong

in code generation for low-end devices like FP-

GAs or embedded computers.This is the result

of dataﬂow paradigm’s strong focus on high-

speed computing. IoT system components in-

clude server backends, with a different set of pro-

gramming languages. Orcc used to have a Java

backend but it was obsoleted. We plan to include

into the IoT version a Java backend with server

ﬂavour like Spring Boot

• An Orcc application currently must deﬁne all the

https://spring.io/projects/spring-boot

actors in the graph. The requirement is that IoT

system designers be able to select a wide variety

of actors so that IoT applications can be composed

quickly. This requires an actor library support.

3 HETEROGENEOUS CODE

GENERATION FOR IoT

The heterogeneous compiler is the main difference

between the traditional dataﬂow applications opti-

mized for high-speed computing and the IoT appli-

cations. Heterogeneous dataﬂow has been a major

research topic (e.g. (Bezati et al., 2014)) but prior

research mainly concentrates on multiple processing

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

428

cores (of same type like multicore or of different types

as CPU-GPU) integrated into the same computing

hardware, often on the same chip. As discussed in

section 1, IoT applications are inherently heteroge-

neous and distributed with communication links that

can be unreliable (like short-range communication

links) and/or slow (like low-power WANs).

Figure 3 demonstrates, how the heterogeneous

code generator backend ﬁts into the Orcc architec-

ture. The heterogeneous backend knows, which parts

of the dataﬂow application are assigned to which ho-

mogeneous backend, partitions the graph and hands

parts of the graph to their associated homogeneous

code generators.

Figure 3: Heterogeneous code generator architecture.

3.1 Architecture

The basic principle of a heterogeneous platform is

that they contain multiple processing elements with

different kinds of computational units. We can de-

scribe the architecture of an heterogeneous platform

with three components: Processing element (PE),

Medium and Link.

A PE models the processing element type, it is

used to describe the main properties of a computa-

tional unit available on a given platform. A PE may

refer to any element in the IoT architecture that is ca-

pable of being part of the dataﬂow network, i.e. can

produce or consume data items (tokens in dataﬂow

parlance). A PE therefore can be a sensor that can

produce tokens, an embedded computer or IoT appli-

cation gateway that can run part of the dataﬂow net-

work or a server instance.

A Medium models a communication channel or a

memory, it is used to describe the kind of communi-

cation that a PE communicates with another PE or an

external communication channel. A Link describes

the properties of the interface between a PE and a

Medium.

A PE might be represented as nested PE in or-

der to represent a multi-core or many-cores comput-

ing device. As an example the architecture of the

BCM2837B0

ARM_0 ARM_1

ARM_2 ARM_3

DDR

Bluetooth

WIFI

ETH

USB

Figure 4: Architecture of the Raspberry Pi 3B+.

Rasberry Pi B+ is depicted in Figure 4. A Rasberry

Pi B+ contains a Broadcom A-53 ARM processor

(BCM2837B0) with four processing units and variety

of media that can be interconnected with it. In addi-

tion, the architecture on Figure 4 represents the de-

vice as a standalone platform without any other plat-

form connected to it. Furthermore, this architecture

is sufﬁcient for describing a Raspberry Pi that runs an

operating system that controls all the interfaces and it

provides four processing cores. A dataﬂow applica-

tion can map actors to each ARM core.

BCM2837B0

ARM_0 ARM_1

ARM_2 ARM_3

WIFI

XEON E2176M

X86_0

Bluettoth

RISC

Temp

Sensor

X86_1 X86_2

X86_3 X86_4 X86_5

Figure 5: An heterogeneous architecture thats contains a

server and an embedded device that receives the tempera-

ture data.

Figure 5 depicts an heterogeneous platform com-

posed of a server that contains a Xeon processor with

six PEs, an embedded Raspberry Pi that communi-

cates with the server via WiFi and a RISC IOT device

that captures the ambient temperature and sends its

data to the Raspberry Pi through Bluetooth. The me-

dia present in Figure 4 but not used by this dataﬂow

application is omitted in Figure 5.

Using this architecture representation the dataﬂow

application will map its actors to each processing ele-

ment and the actor FIFOs are mapped to links which

are connected to the deﬁned media.

Dataﬂow-based Heterogeneous Code Generator for IoT Applications

429

3.2 Mapping Conﬁguration

Orcc supports the mapping of actors to different PEs

on a platform that supports POSIX threads for the C

backend, but it does not provide a mechanism to rep-

resent the architecture of a platform or to generate

code for heterogeneous platforms. The current map-

ping conﬁguration in Orcc is called XCF for XML

conﬁguration ﬁle.

1 <?xml version="1.0" encoding="UTF-8"?>

2 <Configuration>

3 <Partitioning>

4 <Partition id="1">

5 <Instance id="source"/>

6 </Partition>

7 <Partition id="2">

8 <Instance id="sink"/>

9 </Partition>

10 </Partitioning>

11 </Configuration>

Figure 6: Example XCF of ORCC C backend ﬁle with two

partitions.

The XCF represented in Figure 6 indicates that the

generated code has to place actor source to partition

1 and actor sink to partition 2. In the context of the

Orcc C backend, it means that two threads on system

that supports POSIX threads are going to be created

and the actors source and sink are going to run in par-

allel. Furthermore this format does not specify which

network is being used for this dataﬂow application.

This format in its current form can only be used

for assigning runtime actors to different threads. In-

stead of using XCF just for partitioning, here we pro-

pose an extended version of the XCF format that can

be used as input for Orcc to generate source code for

heterogeneous platforms and can inherently describe

the architecture of a platform.

As it can be seen, the XCF conﬁguration ﬁle in

its current format can not be used for heterogeneous

computing and therefore the format has to be ex-

tended. First, the XCF needs to describe which is

the top Network of the application that is going to

be used. Thus, the XCF is coupled with a dataﬂow

network or even multiple such networks. Second, it

needs to give explicit information about the Parti-

tioning of the application to an heterogeneous plat-

form. The XCF ﬁle also needs to describe which PE

this partition is going to be associated to and the back-

end that is going to be used to generate the code.

The XCF ﬁle also includes the notion of a host.

A host can describe a platform that contains differ-

ent PEs with the same processing core architecture

(e.g a PC with multicore Intel processor) or different

1 <?xml version=”1.0” encoding=”UTF−8”?>

2 <Conﬁguration>

3 <Network ﬁle−format=”xdf” qualiﬁed−id=”AHU Unit”/>

4 <Partitioning>

5 <Partition id=”server 0” pe=”x86 0” backend−id=”Java Server” host=”

intel server”>

6 <Instance id=”weather forecast temperature”/>

7 <Instance id=”weighted average”/>

8 <Instance id=”power attenuator”/>

9 <Instance id=”cold room power estimator”/>

10 </Partition>

11 <Partition id=”server 1” pe=”x86 1” backend−id=”Java Server” host=”

intel server”>

12 <Instance id=”pid controller”/>

13 </Partition>

14 <Partition id=”air temp 0” pe=”ARM” backend−id=”Java 0”>

15 <Instance id=”return air temperature”/>

16 </Partition>

17 <Partition id=”air temp 1” pe=”ARM” backend−id=”Java 0”>

18 <Instance id=”outdoor air temperature”/>

19 </Partition>

20 <Partition id=”fan power” pe=”ARM” backend−id=”Java 1”>

21 <Instance id=”supply fan power”/>

22 </Partition>

23 </Partitioning>

24 <Backends>

25 <Backend id=”Java Server” backend=”Java Server”/>

26 <Backend id=”Java 0” backend=”Java Vanilla”>

27 <Parameter key=”Board” value=”BeagleBone Black Wireless”/>

28 </Backend>

29 <Backend id=”Java 1” backend=”Java Vanilla”>

30 <Parameter key=”Board” value=”BeagleBone Black Wireless”/>

31 </Backend>

32 </Backends>

33 <Media>

34 <Interface id=”wiﬁ” medium=”Wiﬁ”>

35 <Parameter key=”Server IP Address” value=”192.168.0.1”/>

36 </Interface>

37 </Media>

38 <Connections>

39 <Fifo−Connection src=”return air temperature” src−port=”Out” dst=”

pid controller” dst−port=”operand 1” size=”512” medium−id=”

wiﬁ”/>

40 <Fifo−Connection src=”weighted average” src−port=”Out” dst=”

pid controller” dst−port=”operand 2” size=”512” medium−id=”

wiﬁ”/>

41 <Fifo−Connection src=”pid controller” src−port=”Out” dst=”

power attenuator” dst−port=”operand 1” size=”512” medium−

id=”wiﬁ”/>

42 <Fifo−Connection src=”outdoor air temperature” src−port=”Out” dst=”

weighted average” dst−port=”operand 1” size=”512” medium−

id=”wiﬁ”/>

43 <Fifo−Connection src=”power attenuator” src−port=”result” dst=”

supply fan power” dst−port=”In” size=”512” medium−id=”wiﬁ

”/>

44 </Connections>

45 </Conﬁguration>

Figure 7: AHU XCF ﬁle.

ones (e.g. the Zynq 7000 is composed with two ARM

processors and an FPGA). Thirdly, it needs to pro-

vide a set of Backends and how they are conﬁgured.

Fourthly, it needs to describe the different Media used

for this conﬁguration and its attributes. And ﬁnally, it

needs to describe the Connections between the PE

and the Media.

Figure 7 represents the XCF ﬁle of the AHU unit

dataﬂow application of Figure 2. The dataﬂow appli-

cation is mapped onto 5 partitions: server 0, server 1,

air temp 0, air temp 1 and fan power. The server 0

contains four instantiated actors and server 1 con-

tains one instantiated actor. Both those partitions run

in parallel on the same machine as indicated by the

host intel server. All other partitions run in differ-

ent embedded platforms and contains one instanti-

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

430

server_1

pid_controller

Out

operand_1

operand_2

pid_controller

Out

operand_1

operand_2

server_1

pid_controller

Out

operand_1

operand_2

air_temp_0

return_air_temperature

Out

return_air_temperature

Out

air_temp_0

return_air_temperature

Out

fan_power

supply_fan_power

fan_power

supply_fan_power

air_temp_1

outdoor_air_temperature

Out

outdoor_air_temperature

Out

air_temp_1

outdoor_air_temperature

Out

server_1

weather_forecast_temperature

Out

weather_forecast_temperature

Out

cold_room_power_estimator

Out

cold_room_power_estimator

Out

weighted _av erage

Out

operand_1

operand_2

weighted _av erage

Out

operand_1

operand_2

power_attenuator

Out

operand_1

operand_2

power_attenuator

Out

operand_1

operand_2

server_1

weather_forecast_temperature

Out

cold_room_power_estimator

Out

weighted _av erage

Out

operand_1

operand_2

power_attenuator

Out

operand_1

operand_2

Java Server Java 0 Java 1

Backends

Java Server Java 0 Java 1

Backends

Wifi

Media

Wifi

Media

Figure 8: Visualization of the XCF deﬁned in Figure 7.

ated actor. Three backends have been deﬁned: one

for Java server-based applications and two for plain

java code generation. Here we should mention that

the proposed XCF format permits the same backend

with different parameters such as the backends with

ids Java 0 and Java 1. All the PEs communicate

through one medium called ”Wiﬁ”. The ip address

of this medium can be passed as a parameter, as indi-

cated in line 34 of Figure 7. The three embedded de-

vices are connected to the server via FIFOs under the

medium ”Wiﬁ”, as deﬁned in lines 40, 41 and 42 of

Figure 7. Finally, the connections of the result port of

weighted average and result port of pid controller are

omitted and should not be deﬁned in the XCF because

there are internal FIFOs and server 0 and server 1

partitions are Java threads that run in parallel.

WIFI

ARM ARM ARM

X86_0 X86_1X86_0 X86_1

Figure 9: V the XCF deﬁned in Figure 7.

Figure 8, visualizes the XCF of the Figure 7. The

ﬁve partitions are subnetworks of the original network

of Figure 2. Three backends have been deﬁned with

different colors, every parition is colored with a cor-

respoding backend. For this example only one Media

has been used. The same color as the Media has been

used for depicting the interconnection among the par-

titions. Finally, given the proposed XCF ﬁle structure,

the architecture of a platform can be extracted directly

as depicted in Figure 9. Thus, this extended XCF ﬁle

describes how different heterogeneous platforms are

interconnected and conﬁgured but also represents the

architecture of the overall heterogeneous systems.

4 CONCLUSIONS AND FURTHER

WORK

This paper presented an ongoing work to extend an

open-source dataﬂow environment with IoT features.

We argue that the dataﬂow application model suits

a wide variety of IoT systems, providing a solution

to the IoT heterogeneity platform problem, bridg-

ing the gap between the physical engineering system

(like an industrial process) and its associated IoT pro-

cess chain and even improving the security. There

are some differences, however, between the usage of

dataﬂow model in its established, high-speed comput-

ing use cases and the proposed IoT use cases. The

most important difference is the inherent heterogene-

ity of IoT systems and the presence of the short-range

and wide-area network links that come with this het-

erogeneity. Our proposed extensions address this is-

sue.

The feasibility of Orcc-IoT’s dataﬂow approach

Dataﬂow-based Heterogeneous Code Generator for IoT Applications

431

and heterogeneous code generation for IoT will be de-

moed in an air conditioning system for aircraft sim-

ulators. Orcc-IoT will be published as open-source

software under the original Orcc license (BSD).

REFERENCES

Bezati, E., Thavot, R., and et al., G. R. (2014). High-level

dataﬂow design of signal processing systems for re-

conﬁgurable and multicore heterogeneous platforms.

J Real-Time Image Proc (2014) 9: 251.

Gazis, V., Goertz, M., Huber, M., Leonardi, A., Math-

ioudakis, K., Wiesmaier, A., and Zeiger, F. (2015).

Short paper: Iot: Challenges, projects, architectures.

In 2015 18th International Conference on Intelligence

in Next Generation Networks, pages 145–147.

Giang, N. K., Blackstock, M., Lea, R., and Leung, V. C.

(2015). Developing iot applications in the fog: A dis-

tributed dataﬂow approach. In 2015 5th International

Conference on the Internet of Things (IOT), 2015 Oct.,

Seoul, South Korea. IEEE.

Harrand, N., Fleurey, F., Morin, B., and Husa, K. E. (2016).

Thingml: A language and code generation frame-

work for heterogeneous targets. In Proceedings of the

ACM/IEEE 19th International Conference on Model

Driven Engineering Languages and Systems, MOD-

ELS ’16, pages 125–135, New York, NY, USA. ACM.

ISO/IEC (2012). ISO/IEC 23001-4, Information technology

MPEG systems technologies Part 4: Codec conﬁgu-

ration representation.

Milutinovi

c, V., Salom, J., Trifunovic, N., and Giorgi, R.

(2015). Guide to DataFlow Supercomputing: Ba-

sic Concepts, Case Studies, and a Detailed Example.

Springer.

Sourceforge (2014). Orcc : Dataﬂow programming made

easy, http://orcc.sourceforge.net/.

Tau

san, N., Markkula, J., Kuvaja, P., and Oivo, M.

(2016). Choreography modelling in embedded sys-

tems domain: Requirements and implementation

technologies. In 4th International Conference on

Model-Driven Engineering and Software Develop-

ment, MODELSWARD 2016, pages 75–86, Rome.

IEEE.

Yaqoob, I., Ahmed, E., Hashem, I. A. T., Ahmed, A. I. A.,

Gani, A., Imran, M., and Guizani, M. (2017). Internet

of things architecture: Recent advances, taxonomy,

requirements, and open challenges. IEEE Wireless

Communications, 24(3):10–16.

Yasumoto, K., Yamaguchi, H., and Shigeno, H. (2016). Sur-

vey of real-time processing technologies of iot data

streams. In Journal of Information Processing Vol.24

No.2 195202 (Mar. 2016). IPSJ.

Yviquel, H., Lorence, A., Jerbi, K., Cocherel, G., Sanchez,

A., and Raulet, M. (2013). Orcc: Multimedia de-

velopment made easy. In Proceedings of the 21st

ACM International Conference on Multimedia, MM

’13, pages 863–866, New York, NY, USA. ACM.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

432