The document discusses building an open source IoT cloud stack using Eclipse projects. It describes typical IoT applications with devices, cloud and applications. It then introduces the Eclipse Kura project, which provides an open source device gateway. The Eclipse Hono project provides a scalable and secure messaging connector. Finally, the Eclipse Kapua project aims to provide a complete open source IoT cloud solution with services for device and data management. The stack is designed to be scalable, secure and maintainable for building IoT solutions.

1. BUILDING OPEN SOURCE IOT CLOUD
Dejan Bosanac

2. WHO AM I?
Dejan Bosanac
• Senior Software Engineer at Red Hat
• Messaging and Integration background (ActiveMQ, Camel, Fabric8)
• Focused more on messaging and backend for IoT lately

3. AGENDA
• Describe typical IoT application
• Describe all the components and common pitfalls
• Introduce Eclipse IoT projects to the rescue
• Kura
• Hono
• Kapua
• Future

4. IOT APPLICATIONS

5. Devices
Cloud
Applications
IOT APPLICATIONS
Device
Device
Applica+on
Device Applica+on
Applica+on IOT Cloud

6. DEVICES
• Everything from simple sensors to small computers
• Connectivity
• Some are IP enabled
• Some have just near-range connectivity, like Bluetooth
• Variety of network protocols used (MQTT, LWM2M,…)
• Functions
• Sensors – send data – temperature sensor
• Actuators – control environment – A/C Unit

7. APPLICATIONS
• Enterprise applications, micro-services and everything in between
• Want to use data generated by devices
• Want to control devices
• Want to control the cloud environment … more about that in a minute

8. CLOUD
• Connects devices and applications
• Provides connectivity layer
• Provides security layer
• Provides device state
• Handle device data

9. PITFALLS
• Create a silo application
• Hard to upgrade and maintain
• Solution don't scale
• Security is an afterthought

10. SOLUTION
• Build well maintained open source stack
• Scalable, secure and maintainable
• Developers should focus on devices and applications

11. STACK
• Device Gateway - Eclipse Kura - https://www.eclipse.org/kura/
• IoT Connector – Eclipse Hono - https://projects.eclipse.org/projects/iot.hono
• IoT Cloud – Eclipse Kapua - https://projects.eclipse.org/projects/iot.kapua

12. GATEWAY

13. DEVICE GATEWAY
• Device IP onboarding
• Data pre-processing
• Control devices
• Operational management

14. GATEWAY ARCHITECTURE
Data Center
Gateway
Application
Sensors

15. INSERT DESIGNATOR, IF NEEDED15
KURA ARCHITECTURE

16. KURA SERVICES
• I/O Services – serial, Bluetooth, GPS, …
• Data services - Store and forward data using MQTT, Apache Camel
• Cloud services – request/reply
• Configuration service – OSGi configuration
• Web administration interface

17. KURA APPLICATION
• OSGi Bundle
• Deployed and managed by Kura
• Using Kura APIs to communicate with devices and cloud
• Apache Camel Integration

18. KURA APPLICATION
public void setCloudService(CloudService cloudService) {
cloudService = cloudService;
}
protected void activate(ComponentContext componentContext, Map<String, Object> properties) {
...
// Acquire a Cloud Application Client for this Application
cloudClient = cloudService.newCloudClient("greenhouse");
cloudClient.addCloudClientListener(this);
...
}
protected void doPublish() {
...
KuraPayload kuraPayload = new KuraPayload();
kuraPayload.addMetric("temperature", temperature);
cloudClient.publish("sensors", kuraPayload, DFLT_QOS, DFLT_RETAIN,DFLT_PRIORITY);
...
}

19. KURA CAMEL
public class MyKuraRouter extends KuraRouter {
@Override
public void configure() throws Exception {
from("timer://heartbeat").
setBody(constant("Hello")).
to("kura-cloud:myApplication/myTopic");
}
}

20. CONNECTOR

21. CONNECTOR
• Messaging infrastructure that connects gateways and applications
• Eclipse Kura uses MQTT
• Usually combined with message brokers like Apache ActiveMQ or Eclipse Paho

22. MQTT
• OASIS standard (v3.1.1)
• Created by IBM and Eurotech
• Lightweight
• Small network message
• Simple protocol
• Pub / Sub
• Quality of Service
• Connection failures
• Very popular in IoT scenarios

23. LIMITATIONS
• Scalability
• Connections
• Destinations
• Security based on broker addresses
• General purpose messaging
• No message format

24. ECLIPSE HONO – GOALS
• Tailored general messaging for IoT solutions
• Solve recurring problems
• Provide messaging APIs for common operations
• Support multiple IoT protocols (MQTT, AMQP, LWM2M,…)
• Support any underlying messaging infrastructure
• JMS
• Kafka

25. ECLIPSE HONO – FEATURES
• Scalability
• Multi-tenancy
• Device-based security
• Multi-protocol support

26. ECLIPSE HONO – APIS
• AMPQ 1.0 based
• Defines message formats coming in and out of Hono
• Defines message exchange patterns

27. INSERT DESIGNATOR, IF NEEDED27
AMQP
• International Standard (ISO/IEC ISO 19464)
• Binary Protocol
• Rich feature set:
• conversation multiplexing
• advanced flow control
• Type system
• QoS Guarantees
• Symmetrical message exchange
• No Broker required

28. INSERT DESIGNATOR, IF NEEDED28
AMQP
Message(
properties: {
correlation-id: 1,
to: "$management",
reply-to: "/myaddress"
},
application-properties: {
"name" -> "newQueue",
"operation" -> "CREATE",
"type" -> "org.example.queue"
},
application-data: AmqpValue(
Map(
"max_size" -> "2000Mb"
)
)
)

29. • It is not a broker
• It never owns a message
• It propagates AMQP transfer, settlement and disposition frames between endpoints
• Message based or link based routing
AMQP ROUTER
Router
/device1
/device2

30. INSERT DESIGNATOR, IF NEEDED30
AMQP ROUTER
• It can be deployed in multiple router-broker-endpoint topology
• Redundant paths
• Benefits
• Better scaling due to more focused tasks
• Smart routing can be used to partition the traffic
• Ideal candidate for gateway into the system

31. INSERT DESIGNATOR, IF NEEDED31
SCALABLE MESSAGING
• Combination of brokers and routers provides powerful tool box
• Brokers should focus on storing messages
• Routers should do the rest
• Allows for horizontal scaling topologies that can solve IoT challenges

32. ECLIPSE HONO- APIS
• Telemetry
• Command and Control
• Device Registration
• Device Lifecycle

33. ECLIPSE HONO – ARCHITECTURE
MQTT
Device
LWM2M
Device
AMQP
Device
HONO
Protocol
Adapter
Protocol
Adapter
Device
Management
Data
Collec+on
AMQP
AMQP
AMQP
AMQP AMQP

34. ECLIPSE HONO – ARCHITECTURE
• Protocol Adapters
• Stateless
• Provide conversion to common protocols used in IoT
• MQTT
• LWM2M
• HTTP/Rest
• Clients – devices and Cloud services
• Connects using AMQP using well defined APIs

35. ECLIPSE HONO – ARCHITECTURE
Client
Client
Client
Router
Network
Hono
Server
Hono
Server
App
App
Hono
Server
Brokers

36. ECLIPSE HONO – ARCHITECTURE
• Hono server
• Stateless – can be scaled
• Validates message format
• Does device-based authentication

37. ECLIPSE HONO – ARCHITECTURE
• Router Network
• Provide connection scalability
• Routes AMQP messages through the system
• Brokers
• Any AMQP 1.0 compatible system
• Used to save persistent messages

38. ECLIPSE HONO – TECHNOLOGY
• Hono server
• Vert.x + Qpid Proton
• Spring Boot
• Docker
• Scalable and Cloud Ready!

39. ECLIPSE HONO – TECHNOLOGY
• Scalable messaging
• Apache Qpid Dispatch Router
• Apache ActiveMQ Artemis
• Scalable and Cloud Ready!

40. ECLIPSE KAPUA

41. ECLIPSE KAPUA – GOALS
• Provide complete IoT Cloud solution
• Define and Implement needed services
• Ready to run

42. ECLIPSE KAPUA – ARCHITECTURE

43. ECLIPSE KAPUA – BACKHAND SERVICES
• Data Management
• Device Registry
• Device Management

44. ECLIPSE KAPUA – FRONTEND SERVICES
• Management Console
• API Gateway

45. ECLIPSE KAPUA - IMPLEMENTATION
• Micro-services oriented
• Pluggable service locator
• Single JVM
• OSGi
• Cloud Deployment

46. ECLIPSE KAPUA – 1.0
• MQTT based
• Apache ActiveMQ in the messaging layer
• JDBC store for services
• Elasticsearch for data store
• Single VM deployment

47. FUTURE
INSERT DESIGNATOR, IF NEEDED47

48. INSERT DESIGNATOR, IF NEEDED48
FUTURE - KURA
• More data pre-processing
• BPM integration
• AMQP support
• Gateway support proxy

49. INSERT DESIGNATOR, IF NEEDED49
KAPUA
• Micorservice implementation
• Docker images
• REST/AMQP APIs
• Hono support

50. KAPUA + HONO

51. CONCLUSION
• Together Kura, Hono and Kapua will be able to answer even the most challenging IOT demands
• Lots of work ahead
• Everything open source
• Backed by big companies, like Red Hat, Eurotech, Bosch, …
• Join the effort

52. THANK YOU
• https://www.eclipse.org/kura/
• https://projects.eclipse.org/projects/iot.hono
• https://projects.eclipse.org/projects/iot.kapua