More Related Content


Dataflow-based heterogeneous code generator for IoT applications

  1. 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)
  2. “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)
  3. 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
  4. 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)
  5. Reality check Design environment: Tridium Niagara, source: CC North Ltd. © 2015
  6. 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 ( 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.
  7. Orcc Environment Typical CAL working environment Package Explorer: Orcc Projects XDF : Network Editor CAL source code editor Orcc Environment
  8. 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
  9. 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)
  10. Describing the heterogeneity
  11. Describing the heterogeneity (2)
  12. Subgraph creation - before
  13. Subgraph creation - after
  14. 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
  15. 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
  16. 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
  17. The day after ● The entire project will be open-source – Currently hosted on but as a private repository ● Ready to pass the baton to interested parties
  18. Demo at 22nd of February, morning session!