Conference PaperPDF Available

Dataflow-based Heterogeneous Code Generator for IoT Applications


Abstract and Figures

The latest wave of connected digital systems, nowadays called Internet of Things (IoT) promises various gains, especially in terms of significant ease of data access. A large number of different platforms for IoT applications, however, makes their development difficult 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 dataflow 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.
Content may be subject to copyright.
Dataflow-based heterogeneous code generator for IoT applications
abor Paller1, Endri Bezati2, Nebojˇ
sa Tauˇ
abor Farkas1and G´
abor ´
echenyi Istv´
an University, Information Society Research & Education Group, Egyetem t´
er 1. Gy ˝
or, Hungary
2streamgenomics Sarl, EPFL Innovation Park, Bˆ
atiment C, Lausanne, Switzerland,,,,
Keywords: dataflow, 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 significant ease of data access. A large number of different platforms for IoT
applications, however, makes their development difficult 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 dataflow 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.
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 efficiency,
immaturity of communication technologies and het-
erogeneity of platforms. None of the hundreds of dif-
ferent IoT platforms reached the sufficient footprint
so that a dominant platform can be identified. 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 findings from the
scientific 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 first 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 identifies 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 specific 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
dataflow 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
the popular Niagara IoT workbench 1. The AHU con-
trols supply and return air flows and several character-
istics of each flow are measured. The measurements
are typically cyclically collected, analysed and actua-
tor values are computed. The calculations often fol-
low the flow of material in the system (in this case,
the flow of air).
One example application for the AHU engine is
depicted in Figure 2. This shows the flow of data
from one processing element to another passing the
control among the devices indicating that the dataflow
paradigm can be used efficiently for these types of ap-
This flow-like nature of IoT data is indicated in
scientific sources. Several realistic use cases in differ-
ent application domains are presented in (Yasumoto
et al., 2016) to argue for the dataflow paradigm. In
the domain of high-speed computing, the dataflow de-
sign environments are most widely used, according
to (Milutinovi´
c et al., 2015). Finally, (Giang et al.,
2015) use distributed dataflow for their framework
where each device executes only part of the full ac-
tor network. All these characteristics indicate that the
dataflow paradigm can be used efficiently for IoT ap-
An approach alternative to the dataflow 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 dataflow 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 dataflow 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 dataflow model
may simplify these server implementations signifi-
This paper is structured as follows. Section 2 de-
scribes the base system we chose for our dataflow-
based IoT design environment and how we propose
to extend it. Section 3 discusses a key component
of the extended system, the heterogeneous dataflow
compiler. Conclusions and further work are proposed
in section 4.
Today, there are literally hundreds of IoT plat-
forms proposed. These software stacks offer data in-
gestion/sending from/to the endpoints, data manage-
ment, visualisation and device management features,
including alarms. Some are offered as installable soft-
ware packages, some are cloud services. So far no
dominant player emerged in the field, 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 dataflow
paradigm as high-level application model and devel-
oped the DFL to represent the applications.
Instead of developing the environment from
scratch, existing dataflow/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-
It is completely open-source under the BSD li-
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. 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 net-
work’s representation in XML format that Orcc
After having selected Orcc as base system, a gap
analysis was performed among the features required
for the IoT dataflow 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
dataflow 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
Figure 1: Air Handling Unit IoT system designed with Tridium Niagara (source: CC North Ltd. c
Figure 2: Example dataflow application for the AHU unit
to assign parts of the dataflow 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 dataflow 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
flavour like Spring Boot 3.
An Orcc application currently must define all the
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.
The heterogeneous compiler is the main differ-
ence between the traditional dataflow applications op-
timized for high-speed computing and the IoT appli-
cations. Heterogeneous dataflow has been a major
research topic (e.g. (Bezati et al., 2014)) but prior
research mainly concentrates on multiple processing
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 fits into the Orcc architec-
ture. The heterogeneous backend knows, which parts
of the dataflow 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 dataflow network, i.e. can
produce or consume data items (tokens in dataflow
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 dataflow 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
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
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 sufficient for describing a Raspberry Pi that runs an
operating system that controls all the interfaces and it
provides four processing cores. A dataflow applica-
tion can map actors to each ARM core.
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 dataflow
application is omitted in Figure 5.
Using this architecture representation the dataflow
application will map its actors to each processing ele-
ment and the actor FIFOs are mapped to links which
are connected to the defined media.
3.2 Mapping configuration
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 configuration in Orcc is called XCF for XML
configuration file.
1<?xml version="1.0" encoding="UTF-8"?>
4<Partition id="1">
5<Instance id="source"/>
7<Partition id="2">
8<Instance id="sink"/>
10 </Partitioning>
11 </Configuration>
Figure 6: Example XCF of ORCC C backend file with two
The XCF represented in Figure 6 indicates that the
generated code has to place actor source to partition
1and 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 dataflow 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 configuration file 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 dataflow
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 file 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 file 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
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 configured.
Fourthly, it needs to describe the different Media used
for this configuration and its attributes. And finally, it
needs to describe the Connections between the PE
and the Media.
Figure 7 represents the XCF file of the AHU unit
dataflow application of Figure 2. The dataflow 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-
ated actor. Three backends have been defined: 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 ”Wifi”. 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 ”Wifi”, as defined 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 defined in the XCF because
there are internal FIFOs and server 0 and server 1
partitions are Java threads that run in parallel.
Figure 8, visualizes the XCF of the Figure 7. The
five partitions are subnetworks of the original network
of Figure 2. Three backends have been defined 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 file structure,
the architecture of a platform can be extracted directly
as depicted in Figure 9. Thus, this extended XCF file
describes how different heterogeneous platforms are
interconnected and configured but also represents the
architecture of the overall heterogeneous systems.
This paper presented an ongoing work to extend
an open-source dataflow environment with IoT fea-
tures. We argue that the dataflow application model
suits a wide variety of IoT systems, providing a solu-
tion to the IoT heterogeneity platform problem, bridg-
1<?xml version="1.0" encoding="UTF-8"?>
3<Network file-format="xdf" qualified-id="AHU_Unit"/>
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="wifi" medium="Wifi">
35 <Parameter key="Server IP Address" value=""/>
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="wifi"/>
40 <Fifo-Connection src="weighted_average" src-port="Out" dst="pid_controller" dst-port="
operand_2" size="512" medium-id="wifi"/>
41 <Fifo-Connection src="pid_controller" src-port="Out" dst="power_attenuator" dst-port="
operand_1" size="512" medium-id="wifi"/>
42 <Fifo-Connection src="outdoor_air_temperature" src-port="Out" dst="weighted_average" dst-
port="operand_1" size="512" medium-id="wifi"/>
43 <Fifo-Connection src="power_attenuator" src-port="result" dst="supply_fan_power" dst-port="
In" size="512" medium-id="wifi"/>
44 </Connections>
45 </Configuration>
Figure 7: AHU XCF file
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
dataflow 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-
The feasibility of Orcc-IoT’s dataflow approach
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).
cold_room_power_estim ator
cold_room_power_estim ator
cold_room_power_estim ator
Java Server Java 0 Java 1
Java Server Java 0 Java 1
Figure 8: Visualization of the XCF defined in Figure 7.
Figure 9: V the XCF defined in Figure 7
Bezati, E., Thavot, R., and et al., G. R. (2014). High-level
dataflow design of signal processing systems for re-
configurable 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 dataflow 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 configu-
ration representation.
c, V., Salom, J., Trifunovic, N., and Giorgi, R.
(2015). Guide to DataFlow Supercomputing: Ba-
sic Concepts, Case Studies, and a Detailed Example.
Sourceforge (2014). Orcc : Dataflow programming made
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.
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.
... 5 Currently, there are many platforms for composing IoT services using dataflows. Examples include Node-RED [83], COMPOSE [214], Glue.Things [116], LabVIEW [135], Paraimpu [215], Virtual Sensors [111], SpaceBrew [216], FogFlow [18], ASU VIPLE [217], ThingNet [126], Calvin [218], IoT Services Orchestration Layer [219], NoFlo [220] and many others [221,222,223,224]. ...
Full-text available
The Internet of Things (IoT) is an emerging paradigm where practically every (physical and virtual) thing will be interconnected through innovative distributed services. Since the number of connected things is rapidly growing, IoT systems will require the composition of plenty of services into complex workflows. Thus, scalability in terms of the size of IoT systems becomes a significant concern. In this paper, we review and evaluate the fundamental semantics of existing IoT service composition mechanisms to determine how well they fulfil the scalability requirements of IoT systems. We identify scalability desiderata and, accordingly, our findings show that dataflows, orchestration and choreography do not fully satisfy such desiderata, unlike a novel composition mechanism called DX-MAN.
Full-text available
Recent years have witnessed tremendous growth in the number of smart devices, wireless technologies, and sensors. In the foreseeable future, it is expected that trillions of devices will be connected to the Internet. Thus, to accommodate such a voluminous number of devices, scalable, flexible, interoperable, energy-efficient, and secure network architectures are required. This article aims to explore IoT architectures. In this context, first, we investigate, highlight, and report premier research advances made in IoT architecture recently. Then we categorize and classify IoT architectures and devise a taxonomy based on important parameters such as applications, enabling technologies, business objectives, architectural requirements, network topologies, and IoT platform architecture types. We identify and outline the key requirements for future IoT architecture. A few prominent case studies on IoT are discovered and presented. Finally, we enumerate and outline future research challenges.
Conference Paper
Full-text available
Software companies that develop embedded systems following the principles of service-oriented architecture can anticipate various benefits from choreography modelling. Current choreography modelling languages, however, have a limited applicability in embedded systems development since they are not expressive enough to capture all the choreography-relevant aspects that are typical in this domain. We tackled this problem by analysing the needs of embedded systems for choreography modelling language. Our analysis was guided by design science and relied on expert interviews, company-specific documents and the relevant literature. The main results of the analysis presented in this paper are a) design requirements addressing the limitations of choreography modelling languages for embedded systems development and b) proposals for modelling language implementation technologies. The feasibility of these results is evaluated by redesigning an existing choreography modelling language and by implementing a prototype editor for the redesigned language.
Conference Paper
Full-text available
In this paper we examine the development of IoT applications from the perspective of the Fog Computing paradigm, where computing infrastructure at the network edge in devices and gateways is leverage for efficiency and timeliness. Due to the intrinsic nature of the IoT: heterogeneous devices/resources, a tightly coupled perception-action cycle and widely distributed devices and processing, application development in the Fog can be challenging. To address these challenges, we propose a Distributed Dataflow (DDF) programming model for the IoT that utilises computing infrastructures across the Fog and the Cloud. We evaluate our proposal by implementing a DDF framework based on Node-RED (Distributed Node-RED or D-NR), a visual programming tool that uses a flow-based model for building IoT applications. Via demonstrations, we show that our approach eases the development process and can be used to build a variety of IoT applications that work efficiently in the Fog.
Conference Paper
Full-text available
Internet of Things (IoT) is a socio-technical phenomena with the power to disrupt our society such as the Internet before. IoT promises the (inter-) connection of myriad of things proving services to humans and machines. It is expected that by 2020 tens of billions of things will be deployed worldwide. It became evident that the traditional centralized computing and analytic approach does not provide a sustainable model this new type of data. A new kind of architecture is needed as a scalable and trusted platform underpinning the expansion of IoT. The data gathered by the things will be often noisy, unstructured and real-time requiring a decentralized structure storing and analysing the vast amount of data. In this paper, we provide an overview of the current IoT challenges, will give a summary of funded IoT projects in Europe, USA, and China. Additionally, it will provide detailed insights into three IoT architectures stemming from such projects.
Conference Paper
Full-text available
In this paper, we present Orcc, an open-source development environment that aims at enhancing multimedia development by offering all the advantages of dataflow programming: flexibility, portability and scalability. To do so, Orcc embeds two rich eclipse-based editors that provide an easy writing of dataflow applications, a simulator that allows quick validation of the written code, and a multi-target compiler that is able to translate any dataflow program, written in the RVC-CAL language, into an equivalent description in both hardware and software languages. Orcc has already been used to successfully write tens of multimedia applications, such as a video decoder supporting the new High Efficiency Video Coding standard, that clearly demonstrates the ability of the environment to develop complex applications. Moreover, results show scalable performances on multi-core platforms and achieve real-time decoding frame-rate on HD sequences.
Conference Paper
One of the selling points of Model-Driven Software Engineering (MDSE) is the increase in productivity offered by automatically generating code from models. However, the practical adoption of code generation remains relatively slow and limited to niche applications. Tooling issues are often pointed out but more fundamentally, experience shows that: (i) models and modeling languages used for other purposes are not necessarily well suited for code generation and (ii) code generators are often seen as black-boxes which are not easy to trust and produce sub-optimal code. This paper presents and discusses our experiences applying the ThingML approach to different domains. ThingML includes a modeling language and tool designed for supporting code generation and a highly customizable multi-platform code generation framework. The approach is implemented in an open-source tool providing a family of code generators targeting heterogeneous platforms. It has been evaluated through several case studies and is being used for in the development of a commercial ambient assisted living system.
Recently, Internet of Things (IoT) has been attracting attention due to its economical impact and high expectations for drastically changing our modern societies. Worldwide by 2022, over 50 billion IoT devices including sensors and actuators are predicted to be installed in machines, humans, vehicles, buildings, and environments. Demand is also huge for the real-time utilization of IoT data streams instead of the current off-line analysis/utilization of stored big data. The real-time utilization of massive IoT data streams suggests a paradigm shift to new horizontal and distributed architecture because existing cloud-based centralized architecture will cause large delays for providing service and waste many resources on the cloud and on networks. Content curation, which is the intelligent compilation of valuable content from IoT data streams, is another key to fully utilize and penetrate IoT technologies. In this paper, we survey the emerging technologies toward the real-time utilization of IoT data streams in terms of networking, processing, and content curation and clarify the open issues. Then we propose a new framework for IoT data streams called the Information Flow of Things (IFoT) that processes, analyzes, and curates massive IoT streams in real-time based on distributed processing among IoT devices.
The potential computational power of today multicore processors has drastically improved compared to the single processor architecture. Since the trend of increasing the processor frequency is almost over, the competition for increased performance has moved on the number of cores. Consequently, the fundamental feature of system designs and their associated design flows and tools need to change, so that, to support the scalable parallelism and the design portability. The same feature can be exploited to design reconfigurable hardware, such as FPGAs, which leads to rethink the mapping of sequential algorithms to HDL. The sequential programming paradigm, widely used for programming single processor systems, does not naturally provide explicit or implicit forms of scalable parallelism. Conversely, dataflow programming is an approach that naturally provides parallelism and the potential to unify SW and HDL designs on heterogeneous platforms. This study describes a dataflow-based design methodology aiming at a unified co-design and co-synthesis of heterogeneous systems. Experimental results on the implementation of a JPEG codec and a MPEG 4 SP decoder on heterogeneous platforms demonstrate the flexibility and capabilities of this design approach.
Orcc : Dataflow programming made easy
  • Sourceforge
Sourceforge (2014). Orcc : Dataflow programming made easy,
Guide to DataFlow Supercomputing: Basic Concepts, Case Studies, and a Detailed Example
  • V Milutinović
  • J Salom
  • N Trifunovic
Milutinović, V., Salom, J., Trifunovic, N., and Giorgi, R. (2015). Guide to DataFlow Supercomputing: Basic Concepts, Case Studies, and a Detailed Example. Springer.